Every year it is increasingly difficult to get these updates out in time. So it's a bit weird to be writing this 2024 year in review post while it's already halfway into 2025. I do like being able to write down my thoughts and reflections of the past year, so I'm publishing this review regardless.

In my previous year in review I wrote that 2023 had been a rather stable year with clear upward trajectory, in business as well as personally. That place of stability had been a very welcome change from the hectic years before. And this has allowed me to start focusing on some parts of life that had been neglected.

💰 Revoke.cash & Entrepreneurship

It's been over 2 years now since I decided to work on Revoke.cash full-time, and 2024 has been the best year yet. We crossed the threshold of over 100 different crypto networks supported and grew the team beyond myself. We received a lot of support and public goods funding, and shipped loads of new features.

Rebranding

While the clip-art logo that Revoke has had for the past years has served us well, it was time to retire the old brand in favour of one that wasn't made by me in about 10 minutes time.

For the new brand and logo we worked together with Richard Schumann, a Berlin-based designer that has provided us with very high quality work and an enjoyable collaboration. As part of the rebrand we also redesigned the browser extension, that was in dire need of some UI love.

Batch Revoking

One of the most requested features since Revoke's inception is the infamous batch revoke. And while our answer has always been that it is not possible to revoke multiple approvals in a single transaction, we have finally launched a UI overhaul that makes queuing up these individual transactions much easier.

And with native account abstraction around the corner for Ethereum, chances are that it will finally also be possible to combine multiple revokes into a single transaction.

Risk Indicators

Another feature that had been on the backlog for quite some time was better risk indicators to offer guidance for which token approvals might be higher risk or even outright malicious.

For this feature we partnered with ScamSniffer and Webacy, and we've also built our own risk engine. I want to continue building out this risk engine to help users gain better insights into their token approvals.

Revenue

2024 has been a great year for public goods funding across the crypto ecosystem. We've received large grants from Optimism's Retro Funding, Gitcoin, Octant and ENS. This has allowed us to hire some part time contractors to help me out with the company.

While revenue has been great, it is uncertain what 2025 will bring, which is unfortunately the nature of the business model that I'm trying to pursue as a public good. It may prove difficult, but I do want to try to continue building Revoke as a public good.

I've chatted with people at Optimism, and unfortunately it looks like Revoke will not be eligible for the next wave(s) of Optimism Retro Funding. I am grateful to them for their support in 2024, and it will be a big challenge to find a replacement for that revenue stream in 2025.

👨‍🎨 Side Projects

Side projects have always been a big part of what I do, but in the past years they have been becoming less prominent. Especially after Revoke.cash graduated from side project to main project. But some projects are still holding on strong and some new projects have emerged.

CashScript

As I wrote in my previous year in review post, the Truffle Suite of developer tooling was sunset late 2023, and with it my popular open source truffle-related tools. So while I used to work on several open source developer tools in the past, only one remains: CashScript.

As a reminder, CashScript is a project that I created in 2019 as part of my Master's Thesis. Over the years it grew to the primary way to create smart contracts on Bitcoin Cash. And while my main focus is on the Ethereum ecosystem, it is great to see that CashScript is still growing, and I still dedicate some weekly time to it together with Mathieu Geukens who has been a part of the team since 2023.

Its usage has kept rising in 2024, and while the BCH ecosystem is only a fraction of the size of Ethereum, it is very cool and rewarding to see that CashScript is being used to create dozens of novel DeFi applications, like derivatives platform AnyHedge and stablecoin Moria.

ForestComply

Another side project that I've started this year is ForestComply. This is a product that came about after I spoke with my uncle Albert, who runs Crafting Markets, a company that imports and trades cacao beans.

The EU has developed new regulations surrounding the importing of cacao and coffee beans, timber, rubber, and several other commodities. Central to this new European Deforestation Regulation (EUDR) is that traders need to provide documentation that shows that their commodities do not come from deforested areas.

To help traders comply with this new regulation, my friend Dries and I started ForestComply, a product that uses open source satellite data to detect deforestation in common origins of cacao and coffee. Our aim with this product was to provide a fairly priced usage-based alternative to some of the overly expensive solutions on the market.

We spoke to potential users and developed a quite complete solution, and we even booked a week in a cabin to make sure we get all the important features implemented. But when the new regulation ended up being postponed by at least another year, we lost the motivation to continue working on it without a clear path to revenue.

We decided to shelve the project with the option to pick it back up if the regulation does end up being implemented, but we are dealing with the European Union, and with the current delays it would not surprise me if the regulation gets pushed even further or even completely removed.

💪 Quality of Life

The past years have been very much focused on work: first my salaried & freelance work, then building my own companies. As I've shared in my previous year in review posts, I've been gradually trying to find more balance in my life. And because Revoke has been steadily growing, I've been able to spend some more energy on other parts of life that had been somewhat neglected.

Around-the-World Trip

Back in 2019 my wife Kiki and I flew around the world twice, which is an experience we've wanted to repeat for a long time, but never had the opportunity to. Because doing another long trip around the world is something that we've wanted to do for so long, we're very happy that we managed to make it happen in 2024.

We started our trip in February, which was exactly the right time - or maybe even a bit too late - to leave cold Amsterdam behind. Our plan was to just book one way tickets and figure out the next destination along the way. The first stop was driving through the Yucatán peninsula in Mexico.

From there we continued to Hawaii, a place that we also first visited in 2019 on our previous round-the-world trip. When we first visited Hawaii we were still students, so our budget didn't allow for a whole lot of exploration. We made up for that this time around and saw a lot of Oahu in two weeks.

Surprisingly, we were able to get tickets from Hawaii to Melbourne, Australia for just $250 (for a 12 hour flight), so that decision was easily made. We planned to spend a few weeks in Australia, driving from Melbourne to Sydney to Brisbane.

We quickly realised that Australia warrants a much longer stay, so we ended up staying in the country for 5 weeks, which still did not seem nearly enough.

After Australia we got in touch with a friend that we met in Hawaii on our previous trip in 2019 who had since moved to Indonesia. He told us to come over to Sumbawa, so that was our next stop. Unfortunately he ended up not replying once we got to the island, so we didn't get to meet up with him.

Nonetheless, we met some really amazing locals in Sumbawa that made us feel right at home and even invited us into their homes and cooked some delicious meals for us. The nature in Sumbawa was also beautiful, but overall we did miss a bit of the bustle of our other, busier destinations.

In the mean time we had gotten in touch with Håkon, another friend that we'd met on our previous trip in 2019, who happened to also be traveling through South East Asia at the same time. We decided to fly to Bali to hang out with him, and we had a blast with him and met a bunch of other awesome people as well.

From Bali we flew to Singapore to meet family that I had never met before, before making the trip back to Europe with stops in Turkey and Macedonia to visit Kiki's family and our friends Stef and Ana.

This trip is something we'd wanted to do for a long time, so I'm grateful that we had the opportunity to do so in 2024. I was able to continue working on Revoke while travelling, although not as much as I was planning to.

I would like to be able to do another trip like this in the future, but it remains a challenge to combine long travels with work.

Health & Fitness

When I was still studying, I exercised a lot and was in great shape. I cared about eating healthy and I rowed 5 times a week. But in the past years, I had slowly stopped caring about fitness. The pandemic played a role in this, but I also just didn't really have a lot of motivation to work out.

Knowing that it was hard to get back into the habit of working out, I decided to give personal training a go. I was introduced a personal trainer in Amsterdam and I started training with him twice a week after getting back from our travels.

This has made a big impact on my day to day life: I feel much fitter and healthier, and I have a lot more energy to spend on other aspects of life. After experiencing the difference that a relatively small amount of exercise can make, I will make a more conscious effort to keep that going.

Social & Hobbies

Another field where I've been looking to improve is spending more quality time with people I care about. So that means more dedicated time with family, friends and my wife. In 2024, we made an effort to be more aware of this and go out of our way to plan that time and also meet up spontaneously more often.

Because we travelled quite a bit this year, it wasn't always possible to see our loved ones as much as we'd initially had intended. But during our travels, we did make an effort to visit friends across the world where possible, such as our friends in Mexico, Macedonia and the United States.

This year I also decided to make an effort to play more board games, which is a hobby that I've been wanting to get into more. So gnidan inspired me to install the bgstats app, which I've been using to keep track of my board games. I've been having a lot of fun and I'm making a conscious effort to try to meet up for board games more often.

2025

In 2024 Revoke.cash has done well, which has allowed me to focus a bit on things outside of work. While I've reached all of my fitness and travel goals, I still do want to spend more time with people I care about.

2025 looks like it may not be as smooth sailing from a business perspective. So I hope to be able to continue making Revoke.cash a success without taking away from the positive steps I have been taking to improve my life outside of work.

While the past couple of years have been hectic, 2023 feels like it has been surprisingly steady - and has a clear upward trajectory. The year before felt like a roller coaster with incredible highs but also deep lows. That is why stability is a welcome change - and in line with the goals I set a year ago.

💼 Amsterdam Indie Hacker Office

In 2022, my friend Dries and I rented an office for Chaingrep. After Chaingrep fell apart, Dries and I decided to keep the office to work on our own projects. But we had to leave the office in March of 2023, after which we had to go back to working from home. Dries and I met up to work from coffee shops a few days a week, but we missed having an office to go to.

Enter the Amsterdam Indie Hacker Office. In May 2023 I stumbled upon this article from Simple Analytics, the analytics company I use for my projects. The article had a link to the Twitter account of its author Iron Brands (real name 😉).

As luck would have it, Simple Analytics has its office in Amsterdam and was renting out some desks. So after a quick meet and greet, Dries and I moved into this little office filled with other indie hackers and entrepreneurs.

Since then I've learned a lot from the other people in the office and Dries even started a new business together with some of the guys from the office! Having the office to go to and work from has been really awesome, and I would not want to go back to WFH.

💰 Revoke.cash & Entrepreneurship

In 2022 I decided to start working on Revoke.cash full-time and in 2023 this really came to fruition. I've been steadily working on improving the platform and it has seen nice growth over the course of the year.

Redesign

The new year started strong with the launch of the redesigned version of Revoke.cash. While the old version had seen some updates since the initial 2019 launch, it was largely the same as when Revoke.cash started. So it felt quite dated and hard to add new features.

With the 2023 refresh, I updated the platform to make it easier to use and easier for me to add additional functionality in the future. But while I wanted the website to feel more modern, I also didn't want to give up the "signature" black & white look of Revoke.cash. I think I largely succeeded.

Making Money

Since I no longer had a job to help sustain myself and my wife, making money was a high priority. When I started working full time on Revoke.cash in Q4 of 2022, my intention was to add paid premium features to generate an income from Revoke.cash.

A big part of the motivation behind the redesign was also to make it easier to add this kind of functionality by adding more structure to the website. But I found myself spending more time on improving the free product instead of adding paid features.

Sponsorships

Early in 2023 this meant that funding was running very low, and to solve the problem at hand, I considered adding advertisements to the free product as a sort of stopgap solution. However, I did not want to make it an intrusive part of the application.

So rather than traditional advertisements, I decided to see if there were any companies that were interested in more of a "sponsorship" deal, which meant adding sponsor banners to a dedicated section of our landing page / website, without cluttering the actual application UI.

I launched this sponsorships program in February of 2023, and thanks to the help of the initial set of sponsors (Boring Security, PREMINT, Vulcan and Earni.fi) I was able to extend the runway needed to continue working on Revoke.cash.

Public Goods Funding

The initial set of sponsorships helped with extending the runway, but funds were still running lower and the first months of 2023 were pretty stressful. But then something amazing started to happen: Public Goods Funding took off for Revoke.cash.

While we had received a decent amount of donations and grants through Gitcoin Grants already in 2022, 2023 saw a lot more interest in public goods funding. Gitcoin Grants transitioned to its new decentralised system and ran several alpha / beta rounds that brought in funding.

And it was no longer only Gitcoin that was leading the public goods funding effort. In 2023, Optimism launched a massive effort into funding public goods through their RetroPGF program, ENS started a public goods funding / grants program, and the Octant platform sprung up from what used to be the Golem community.

Overall 2023 saw a lot more focus on funding public goods throughout the Ethereum / crypto ecosystem. While it felt hard to depend on these kinds of programs at first, it feels like they are maturing into a viable way to build free and open source software in the crypto industry.

I think it is pretty amazing that the crypto ecosystem has been able to create this kind of culture that wants to fund public goods. Crypto is pretty unique in that aspect, and I think a lot of it is due to the unique financial incentives that exist in crypto.

In the crypto world, it is possible for people to produce positive externalities by funding public goods, while still personally benefiting enough from funding those public goods. This means that we don't just need to rely on the goodness of people's hearts - although that goodness is definitely still much appreciated.

Growing The Team

Around the end of 2023, I ended up in a spot where it looks like Public Goods Funding is a viable revenue model for Revoke.cash and there is still plenty of stuff to build. With that in mind I felt comfortable to slowly expand the team beyond just myself. So in December I hired my friend Dries for a part time software engineering role.

Dries had been helping out as a contractor on several features earlier in the year, such as the new exploit checker. He's currently working on expanding the features around risk insights, and I'm sure he'll contribute a bunch more in 2024.

Exploit Checker

In April of 2023, the crypto world was shaken by an exploit targeting popular DEX SushiSwap. In this hack, a bug in SushiSwap's new router contract was exploited to steal approved user funds.

Because SushiSwap is such an established player, no one expected such an exploit. So this was a wake up call for many people in the space to stay on top of their token approvals. When such an event happens, people rush to Revoke.cash to see if they are affected. But if a user has many token approvals, it can be hard to identify the affected approval. This is what inspired the new Exploit Checker.

I asked my friend Dries to help out as a contractor, and he had the exploit checker implemented in no time. We set it up in such a way that it's super simple to add new checkers whenever exploits happen in the future so that people can easily check whether they have anything to revoke.

Educational Content

Revoke.cash is a great tool to help people stay safe in crypto. But in order to fully stay safe, users also need to be more educated regardless of tooling. To help with that I started writing more educational content on Revoke.cash.

To do so, I created the Learn section / knowledgebase as well as a blog. On the blog I try to post product updates or other event-driven updates about the crypto ecosystem. On the Learn section, I am writing evergreen educational content about crypto and security.

In total, I created a few dozen educational articles and blog posts, so to have a professional illustrator create custom cover images for all of them could become expensive.

With the recent hype around AI, I figured I could try to have ChatGPT generate cover images instead. In the end this took a lot of trial and error, and it definitely wasn't as automated as I'd have preferred, but I think the results ended up great.

Permit2 Approvals

In the world of token approvals, there is a concept of "Permit" signatures. This is a standard to give token approvals using off-chain signatures, rather than requiring on-chain transactions. This is more user-friendly, since a user does not have to send two separate transactions when swapping tokens.

One drawback of these signatures is that only a small subset of tokens supports it. To mitigate that, Uniswap came up with a system they call "Permit2", which enables gasless Permit signatures for every ERC20 token. Championed by Uniswap, Permit2 gained traction in 2023, which meant that it required support on Revoke.cash as well.

Risk Insights

With a bunch of improvements implemented in the past year, one of the biggest topics on the roadmap is providing users with more actionable insights regarding their token approvals. Right now a user logs onto Revoke.cash and is greeted with a big list of token approvals, but it is hard for them to understand what they all mean.

To help users make better decisions for their wallets, I want to provide them with actionable data. In 2023 I already started this by integrating Nefture's wallet health score into Revoke.cash and by integrating pricing information for fungible tokens - making it easier to see how much value is at risk.

This is a great start, but there is still a lot to be done in 2024. First order of business is adding NFT pricing data, since the current pricing data only supports fungible tokens. From there I want to add much more fine-grained risk insights that explain which token approvals are risky and why.

Ledger Connect Kit Hack

While most of 2023 was very positive, halfway into December, we did see a very regrettable event in the Ledger Connect Kit Hack. In this incident, a popular library created by Ledger was compromised and malicious actors were able to inject malicious transactions on websites that used this library - including Revoke.cash.

While the issue was resolved quickly, this event still sent shockwaves throughout the crypto ecosystem, since many popular websites were affected at the same time. Including Revoke.cash, a website that many people visit especially at times like these. Thankfully, Ledger has pledged to compensate all affected users.

🐙 Open Source

As in previous years, my Open Source developer tools were still a pretty important aspect of my 2023. But 2023 also brought some changes.

Truffle Sunset

In the summer Consensys, the company behind development suite Truffle, announced that they would be sunsetting Truffle by the end of the year. Over the years other development tools like Hardhat and Foundry had been taking a lot of market share from Truffle, but its deprecation will still be felt in the Ethereum ecosystem.

I had been maintaining a few libraries that were built on top of Truffle: truffle-plugin-verify and truffle-assertions. With Truffle shutting down its services, I decided to also archive these projects at the end of 2023.

It feels a bit bitter shutting down these projects after maintaining them for many years. But I've also talked about time management in previous year review posts and it is definitely a welcome change to have fewer projects on my hands.

Gratitude

Truffle has played a huge part in my crypto journey. I used it for creating my first smart contracts back in 2018, and TruffleCon 2018 was the first conference I ever spoke at. And of course it spawned my own Truffle-adjacent libraries that were used by thousands of projects over the years and have gotten over a million downloads.

Then I've done contracting work for Truffle on a few super cool features, like the Truffle Dashboard. I've met some great friends through my work on Truffle and my own libraries. So I'm very thankful for the role that Truffle played here.

And of course I want to thank everyone that has used my libraries over the past 5 years and everyone that has contributed to them in that time. In 2023, I specifically want to thank gnidan, Kaan Uzdoğan, d10r, whyvrafvr and zhangtianhao for their open source contributions to truffle-plugin-verify in its final year.

CashScript

Besides my Truffle-related libraries, my other big open source developer tool is CashScript, the smart contract programming language for BCH that I created during my time at Bitcoin.com in 2019. The Bitcoin Cash ecosystem has been adding new smart contract functionality and in 2023 adoption of CashScript has been increasing.

In 2023, Bitcoin Cash added a native token system called CashTokens that enables fungible and non-fungible tokens on Bitcoin Cash as well as expanding general smart contract capabilities. To support these new tokens in CashScript, Mathieu Geukens joined the CashScript team.

With CashTokens implemented, many new smart contract projects were created. These applications were much more sophisticated than most BCH contracts that were created in earlier years. This made us realise that we needed to make it easier to develop these more advanced applications.

As a first step towards this, we created a better, more advanced transaction builder in the SDK to assist with more complex transactions. Shortly after, mainnet_pat helped expand CashScript's debugging functionality with exciting new features. We still need to polish these features and we have some more exciting things planned to help CashScript developers create the best smart contracts they can think of.

🛩️ Travel & Events

With COVID, we hadn't been able to travel as much as we'd have liked in the past years, so we had a lot to make up for. We started 2023 strong with a month-long trip to visit our friend Jenny in New York City and our friends Nick and almost in Philadelphia. The plan was to work and chill, but that turned out to be hard to combine. Nonetheless we had a good time!

Initially we were planning to travel some more in the winter, but after returning from NYC we were happy to be home for a while, so the next trip had to wait until summer.

In May I travelled to Prague to speak at the Prague DeFi Summit and to judge at the ETHPrague hackathon. I had a great time there as it was my first time being a judge in a hackathon, and ETHPrague used a novel judging system based on quadratic voting.

Then in summer it was time for a proper holiday. That meant max 1 hour of work each day, sleeping in, going to the beach and eating amazing food. We returned to our favourite little spot in Sardinia that we'd been before. But this time we brought some of our friends to share the experience.

After Sardinia, we continued with a month of working remotely from Gran Canaria. Chilling + working was a lot easier to combine this time around, and I suspect the nice weather had a lot to do with it. So our next winter trip will definitely not be to a cold place like NYC again.

Then during fall our friends Nick and almost were getting engaged and they invited us to their engagement party in Philadelphia, after which we stayed with them for a while longer. This time around we had a lot more time to explore and enjoy Philadelphia and some of its surroundings, which was lots of fun.

After returning home for just a few weeks, it was time for our final trip of the year, for the much-anticipated Devconnect conference in Istanbul. There I met up with a bunch of friends and we celebrated Kiki's birthday at Nicole, an amazing restaurant in the city.

2023 was definitely a year with some nice trips, but next year I feel like we should be a bit more strategic about them. So that means that it's probably nicer to stay in Amsterdam during the summer and not visit too many cold destinations in the winter.

📈 2024

While 2022 had high highs and low lows, 2023 brought a lot more stability and steadiness. Now, at the start of 2024 I feel like I am in a good place to continue building on the foundations that were laid in the past year. I'm grateful for everything that happened in 2023 and looking forward to 2024.

While 2021 saw the heights of the cryptocurrency market, 2022 kicked off its decline. And by now we're definitely back in a crypto bear market. Not only the crypto market is affected though, since the entire global economy is in recession.

2022 was a turbulent year with a lot of ups and downs, both personally and globally. As the year is coming to an end I feel like I'm back in a similar spot as where I started, albeit with a lot of new experiences under my belt and a lot of new people met.

💍 Getting Married

In 2021 my wife (then girlfriend) told me that if we were to get married, it had to be on a palindrome date. And I did not want to wait for the next good palindrome in 2030. So 22-02-2022 it was.

There were still a lot of COVID rules in place, so we just had a tiny ceremony with a few of our close friends at city hall at 10 in the morning. Afterwards we had lunch at an amazing restaurant, and we finished the day at the beach. We had a great time. For a while it still felt weird to say "my wife", but it's slowly starting to feel more natural.

🚀 Armada & Chaingrep

I ended my previous year in review by looking forward at the months to come and introducing Armada, the startup that I was working on with my friend Merwane. Needless to say, this new startup played a big role in my past year.

Y Combinator

At the start of 2022, Armada was accepted into the W22 batch of Y Combinator, the world's premier startup accelerator. This comprises a three month program in which YC helps you make the most of your startup journey.

The program includes weekly meetings, presentations from the founders of big YC companies - such as Airbnb or Stripe - and tailored advice from the YC partners. The partners are generally also accomplished founders and experts in their fields.

In prior years, YC batches had been in-person at Y Combinator's Bay Area campus, but due to COVID restrictions, the past couple of batches have all been virtual. And while being there in-person would have made it even better, participating in YC has been one of my coolest experiences to date.

PIVAAAT!

As many startup founders know, chances are that your first idea isn't the one that will eventually stick. And while we enjoyed working on our idea for a natural language NFT search engine, we found that was a bit too narrow an idea to build a business on.

So over the months we pivoted several times. We shifted from Armada to Chaingrep, which we described as a "block explorer for humans". This later morphed into a developer-targeted API for human-readable transactions.

After working on that for some months we found ourselves questioning our product again. At this point I was feeling pretty burnt out from all the pivoting while we hadn't actually shipped anything in all those months.

At the same time, Merwane and I had a pretty different outlook on where we wanted to go with the company. So ultimately we decided to split up and go our own ways.

Aftermath

For about 8 months I worked very intensively on trying to build a startup. We went through YC and we raised VC funding. And then it was over. When it happened I had very mixed feelings. Disappointed that we hadn't been able to make it work, but also relieved to take a break from the grind.

I promised myself to take a break at least until October. In that time I went on a few trips abroad and spent some time working on projects, but mainly tried to take it easy.

It's always hard for me to take a full break without doing any kind of work. So I didn't fully succeed at my break, but I definitely did have some weeks where I didn't do any work at all and was able to touch grass in nature.

Now October has come to pass, which means that the time of taking it easy has ended and I'm back to work. Now I'm working my own project again, albeit in a different way: this time as an indie hacker.

🛡 Revoke.cash

Early February we saw a very high-profile phishing scam, startling the entire crypto space. Many people were scared that OpenSea was compromised, which thankfully wasn't the case. But the chaos of this incident brought so much traffic to Revoke.cash that it went down while I was sleeping.

During the first parts of the year I was mainly focused on building Chaingrep, so I didn't spend a lot of time working on Revoke.cash. But after leaving the startup I decided to see how far I could take it.

Browser Extension

Shortly after leaving Chaingrep I built the Revoke.cash browser extension, a kind of "wallet firewall" that pops up with warnings whenever you're about to do something potentially harmful. This is an effective way of combating phishing scams, since phishing websites always try to make you sign something you shouldn't.

The browser extension quickly gained over 10k weekly users, and is still growing. There are several similar projects, which definitely validates the idea. But ultimately I can imagine this kind of functionality being directly integrated into a wallet such as MetaMask.

Multi-chain support

In earlier years I had tried to expand Revoke.cash' functionality to more chains, but never managed to support more than a handful of chains. But with an ever-growing number of chains, it was necessary to support more than just a few.

In 2022 I received grants from RSK and Harmony, which helped realise Revoke.cash' extended multi-chain support. Throughout the year, the number of chains grew, and today more than 30 different chains are supported.

Multi-wallet support

While MetaMask is the largest browser wallet, it definitely isn't the only one, and there's also a growing ecosystem of mobile and desktop wallets. So only supporting MetaMask meant I was missing out on serving a lot of users.

One of Revoke.cash' big strengths is its open source code allowing anyone to contribute to it, so WalletConnect and Coinbase Wallet support was added by contributor Alex McGonagle. I added Gnosis Safe support to that as well, so now Revoke.cash essentially supports every popular wallet on the market.

Localisation

When I was at Devcon in Bogota last October I was confronted with the fact that a lot of people do not speak English at all. To better serve these people I decided it would be good to translate the website. I reached out to some people and got the website and extension translated into Spanish and Chinese.

Looking back, I think the Chinese translation has been very succesful, since a large part of the user base speaks Chinese, and this segment of users grew the most since adding translations. But I'm not sure if the Spanish translation has been worth the effort. Spanish speakers are still only a tiny percentage of users, despite being one of the biggest languages in the world.

Redesign

Now at the start of 2023 I just launched a big overhaul of the website's UI. The old Revoke.cash was created in 2019, and while it has received updates over the years, the UI wasn't the greatest or most flexible.

So with this redesign I hope to make Revoke.cash more accessible to a larger group of users, and I want to make it easier to add more features in the future. My friend Jenny has been a great help with the UX design aspects of the new website.

🤖 FaceFilter.AI

A big theme in 2022 was AI. We saw the advent of DALL-E, a magic AI powered art generator. But as quickly as DALL-E emerged, just as quickly was it supplanted by the open-source alternative Stable Diffusion.

To dive more into AI, my friend Dries and I created FaceFilter.AI, an AI-powered profile picture generator. We were inspired by other apps such as Pieter Levels' AvatarAI and Danny Postma's ProfilePicture.AI. But we added the functionality to write your own "prompts" so that you can go wild with your own creativity.

🖼 Imperfections by Kalis

Last year I shared Imperfections by Kalis, the generative art project I was working on with my dad. In 2022 we finished the project and launched it on Art Blocks, one of the biggest platforms for generative art NFTs.

We organised a small launch event at the OP.ENSPACE gallery in Amsterdam, where we watched as people minted their NFTs. It took a few weeks after the initial launch, but we ended up selling all 450 pieces.

After the launch I created a GitHub template repository with all the boilerplate code that I used during the development of the generative art scripts. So if you're looking to experiment with generative art yourself, be sure to check it out!

🐙 Open Source

While Revoke.cash' popularity soared this year, the usage of my open source developer tooling only grew slightly, peaking at 50k+ monthly downloads. They did reach a different milestone though: 1M combined lifetime downloads!

I shipped some big updates to my open source projects this year. The biggest update was adding support for Sourcify to truffle-plugin-verify. Sourcify is a repository of verified contract source code similar to Etherscan's - but fully open-source. I've been wanting to add Sourcify support for years already, so this was long overdue.

The strength of open source is in its contributors. So for Revoke.cash I want to thank bossyuansu and maorstamati for adding new chains, Alexey Simbirskiy, Michal Šváb and Chawye Hsu for adding new address labels, Dawson Botsford for improving website performance, Diego Mares and Cindy Wang for their translations, and most of all Alex McGonagle for adding WalletConnect support.

For truffle-plugin-verify I want to thank albertov19, Niccolò Petti, nozeroctnellav7, Alejandro Banzas, d10r and Sebastian Baier for adding new chains, and Deniz Surmeli, fuchengshun, Mukundan Senthil, akshaydevh and d10r for contributing new features. And most of all I want to thank Kaan Uzdoğan and Marco Castignoli from the Sourcify team to help realise the Sourcify integration!

For CashScript I want thank Prashant Singh Pawar and mainnet-pat for fixing bugs, Jason Dreyzehner for refactoring internal code, Mathieu Geukens for his work on CashTokens and other improvements and Nathaniel Cherian for adding new features.

🛩️ Events

While crypto events are always fun, they do also tend to take away significant time away from work. And because this year was heavy on work I had to really prioritise the events I wanted to visit. And I knew that the one event I couldn't miss this year was Devcon VI in Colombia.

Because of COVID, it had been 3 years since the last installment of Devcon. Devcon V was the first edition I attended, so I was excited to attend my second one. So in October my wife and I flew 11 hours to Bogotá.

We met a lot of new people and had a lot of fun with old friends as well. And while Colombia isn't on our list of favourite countries, it was great to have a major crypto event in a developing country for a change.

⚖️ Finding Balance

In my last year in review I talked about wanting to set better priorities and learning to say "no" to things that I would love to say "yes" to. Because we just can't do it all. And this is still something I'm struggling with.

I don't regret saying yes to building a startup even if it didn't work out. But there's one important lesson that I learned about priorities during my time working on Chaingrep, somewhat contrary to the ideas I started the year with. And that lesson is finding balance between priorities.

It's good to be focused on just one thing. But while working on Chaingrep I spent day and night just on building the startup. Only to throw away all that work and pivot to something completely different multiple times.

There will certainly be more times where I'll have to throw away work in the future. That is not necessarily a problem. But seeing how often you can fail and restart in a few months does show that you don't need to work day and night to make it work.

So going forward I want to be more balanced in the different aspects of my life. But as I mentioned before, it's generally hard for me to take it too easy. So I expect this to be an on-going challenge for me. We'll see how it goes.

📈 2023

2022 was a rollercoaster. I got married and I am enjoying my new life together with my amazing wife. I also spent a lot of time trying to build a startup and subsequently crashing, but also restarting.

While Chaingrep fell, Revoke.cash flourished. The user base and community is there, but it's not consistently making enough money to sustain myself yet. So in 2023 I want to focus on getting revenue for Revoke.cash. But I want to work on it in a way that complements the rest of my life, rather than consuming it.

In my previous Year In Review I mentioned we were heading into a new crypto bull market, and you can bet that we did. I got into crypto in the middle of the 2017 bull run, so this year was the first bull market I experienced from its onset.

It has mainly been exciting to see a lot of new people enter the space and to see many crypto projects gain legitimacy and mainstream attention. But at the same time it has been difficult to keep up with all the new developments and figure out what to spend my time on.

⛓ Cryptocurrency

Some DeFi tokens such as AAVE had already seen enormous growth in 2020 but many other projects also multiplied over tenfold in 2021. And though most coins have seen both ups and downs, the market as a whole has seen a lot of growth.

We saw the rise of NFTs in generative art and profile pictures and also a subsequent crash of many of these NFT projects. But while many projects are down from their highs it doesn't look like this bull market is over just yet.

AnyHedge

A big part of my year was spent working with General Protocols on AnyHedge, the first DeFi protocol on Bitcoin Cash. This open-source protocol was first integrated into the non-custodial exchange Detoken around the new year, where it saw a volume of over $10m in just a few months.

This kind of volume is only a drop in the ocean compared to the kind of usage that ETH projects enjoy, but it was a good proof of concept to show that it's possible to do DeFi on UTXO-based chains such as BCH, albeit a very different kind.

In the summer Detoken shut down, which left AnyHedge without users. The rest of the year was spent improving the AnyHedge protocol, smart contracts and infrastructure, as well as building a new user-facing application that is set to release in 2022.

CashScript

While working on AnyHedge, CashScript also received some major updates. Most importantly the entire language was overhauled for BCH's upcoming upgrade. The May 2022 network upgrade will bring multiplication and native introspection. When the upgrade hits, covenant contracts will become much more accessible, flexible and efficient. And CashScript will support it from day 1.

Truffle

In my last Year in Review post I mentioned that I would be working with the Truffle team on their upcoming Filecoin integration, which was launched at the end of March. After the successful Truffle + Filecoin launch, I stuck around for another project that we dubbed the Truffle Dashboard.

Previously, deploying contracts with Truffle, Hardhat or similar tools required you to copy-paste a seed phrase to be used for the deployment. But as security guides will tell you, copy-pasting seed phrases is something you generally want to avoid.

So as an alternative, the Truffle Dashboard allows you to use your existing Metamask wallet when deploying smart contracts. I have been quietly working on the dashboard project and it is set to release early in 2022.

Bright Union

Halfway into the year, a friend of mine reached out about Bright Union, a project he started that offers aggregation of DeFi risk coverage. I joined the project as an advisor and I mainly help out with guidance on the Solidity side.

They had a successful product launch for their dashboard that allows you to compare different DeFi coverage products such as Nexus Mutual. They are currently working on expanding their product offering.

🖼 NFTs

The biggest hype this year was definitely NFTs, or Non-Fungible Tokens. While NFTs have been around for close to five years already, 2021 is the year they really picked up steam. Some older collections like CryptoPunks have seen their valuations increase over 50 times. And other wildly successful collections like Bored Ape Yacht Club and Cool Cats were launched and grew to massive valuations within this year.

BASTARD GAN PUNKS

The first NFT collection that I personally fell in love with was BASTARD GAN PUNKS. The bastards are derived from the attributes of the original CryptoPunks. These attributes are passed through a GAN (Generative Adversarial Network) to generate completely new images.

Because the images are generated by AI, some of them look very similar to the original CryptoPunks while others look completely messed up. This has created a collection with incredible diversity and a soul of its own.

ALLBASTARDS.COM

When BASTARD GAN PUNKS launched in March, they had no attributes that they could be filtered on. NFT platforms like OpenSea don't lend themselves very well for collections like that, which made it very difficult to browse the collection.

As a solution I developed the ALLBASTARDS.COM gallery that displays the entire collection in a performant infinite scroll interface. As the community added more metadata attributes to filter on, I expanded the website to include those filters.

Towards the end of the year I started work on implementing a marketplace into ALLBASTARDS.COM, which has been a feature requested by many people within the community. By the end of the year I had gotten pretty far with the implementation, but I also had less and less time, so I asked help from the community.

Since December fellow bastard Christian Reynolds has been doing great work on additional features and final touches for the marketplace. Since he came on board I have mainly been offering guidance while he has been doing most of the development.

Revoke.cash

As you may know, revoke.cash is a project that I started in 2019 that allows you to inspect and revoke all the ERC20 allowances that you've granted to DeFi protocols and other decentralised apps. I've written about this in the past (See Unlimited ERC20 allowances considered harmful), but I hadn't written about how this applies to NFTs.

With the rise of NFTs we're seeing a lot of development at the intersection of NFTs and DeFi as well. Protocols like NFTX or Fractional provide interesting use cases at this intersection. But to use these kinds of applications (or even marketplaces), you need to grant an allowance similar to the one that exists for ERC20 tokens.

As we've observed in the past, more hype also attracts more scams and exploits into the space. So with the hype that NFTs brought it was important to extend revoke.cash to enable inspecting and revoking of NFT allowances as well. I added these features in July and revoke.cash became the first platform for NFT allowances.

Generative art

One big theme of NFTs this year was generative art, meaning that the artist writes an algorithm that is used to produce artworks. This combination of the artist's vision, the algorithm and the aspect of randomness can make for incredibly interesting artworks.

Some famous collections that were created last year are Tyler Hobbs' Fidenza and Dmitry Cherniak's Ringers, but there are hundreds of beautiful collections with hundreds or thousands of artworks per collection.

Seeing the beauty that these algorithms could generate I decided to dive into it myself as well. So in my spare time I have been teaching myself generative art, both through trial-and-error as well as a plethora of online resources, of which Tyler Hobbs' blog has definitely been one of the most useful.

Imperfections by Kalis

My father has been an artist for most of his life, so as I got into generative art I decided it would be a great opportunity to combine our skills and start an art project together. At first he didn't really understand what all these NFTs and generative art were about, but after showing him some existing works he was 100% convinced.

Much of my father's physical work is based around the imperfections that come with the manual execution of otherwise perfect shapes - in his case, stripes. Converting that philosophy from the physical world to a generative digital artwork is a challenge, since the execution of a computer is inherently perfect.

We're both very happy with the progress we've made on the project and the results of the algorithm as it is now. It has also been a great experience to collaborate with my father on a topic like this, since generative digital art is directly at the intersection of our two worlds - art and code.

🎙 Events

As the world got used to COVID we slowly saw more in-person events popping up. We're definitely not back to pre-COVID levels, but there were some great gatherings this year and it looks like the number of events will be ramped up further in 2022.

NFTHack & HackMoney

The first events I attended were still digital. And while I've expressed that I don't particularly enjoy these types of events, I decided to give them another go. I enjoyed working on Radical Domains in 2020 and NFTHack presented itself as a way to work more on harberger taxes and radical markets.

With the new Radical Protocol we set out to generalise the concept of Radical Domains, but for any NFT. Applying this to existing NFTs proved harder than we initially thought, so instead we built a platform that could be used by creators to mint new NFTs under a Harberger system.

This idea landed us a grant from the Rarible DAO, which allowed us to expand this system and we used the subsequent HackMoney hackathon to further the project. While the progress was promising, we had to give up due to lack of time and resources.

EthCC

Come summer, it looked like it was finally time to leave the virtual events behind, as the European Ethereum community gathered in Paris for the fourth annual Ethereum Community Conference. Interesting to note is that EthCC was also the last major conference that wasn't cancelled in 2020.

At EthCC I gave a presentation about the potential dangers of the unlimited allowance pattern that is often used in modern DeFi applications. This is a topic that I wrote about in 2020 and I had been meaning to do a conference talk about for a while now.

Overall it was great to reconnect with a bunch of people that I hadn't seen in years and to connect with some people that got into the space recently as well. But although travel had mostly opened up by that time, most attendees were still EU-based.

ETHLisbon

A couple of months after EthCC travelling became even more widespread and the next big event was the Lisbon Blockchain week, championed by Liscon and ETHLisbon. I wasn't planning to go, but in the end the Truffle team managed to convince me to come over even though I had no tickets to any of the events.

The absence of tickets proved not to be a problem at all as my days were still packed with activities. I had a lot of people to catch up with and a lot of board games to play with the Truffle team back at the hotel, so in the end it was a great success.

A more unfortunate result of the jam-packed weekend of events and meetups was that I tested positive for COVID upon returning home. So what started as a fun break ended up taking quite some time to recover from. It was a great weekend though!

🐙 Open Source

2021 has been a good year for my open source projects. truffle-plugin-verify has ended the year with almost 5x the monthly downloads and revoke.cash ended the year with more than 10x the monthly users.

truffle-plugin-verify and revoke.cash doubled their GitHub Stars while my other projects also saw some growth in stars. My NPM packages now get a combined 35k+ monthly downloads, mostly because of the tremendous growth of truffle-plugin-verify.

A big topic in my open source projects was multi-chain support. 2021 gave rise to a lot of alternative smart contract chains, such as Polygon and Avalanche. truffle-plugin-verify supports most of these alternative chains, while revoke.cash supports a few. It does look like these chains are here to stay so multi-chain support will likely need to be expanded in years to come.

As always, the power of open source is having outside contributors. And like previous years I've had some great help building my open source projects. For revoke.cash I want to thank Dawson Botsford, Merwane Drai, Daniel Heyman, Tim Robinson and Juan Andreu for their contributions.

For CashScript I want to thank Jt Freeman, Sydwell and mr-zwets for their fixes. But most of all I want to highlight Nathaniel Cherian, who implemented several very important features, including tuple assignment and date literals - all while still being in high school!

For truffle-plugin-verify I want to thank oscarmartj, Timon Peng, Jason Smythe, fredlacs, Nhan Cao, albertov19 and Christopher Yu for expanding multi-chain support. I also want to thank Miao ZhiCheng and Kyle Holzinger for expanding and improving the CLI.

📊 Focus & Priorities

One side effect of the bull market is that there's a lot more going on in the space than there was in the years prior. This means that it's inevitably unattainable to keep up with all the development - however interesting they may be. If you combine this with the overflow of new projects that are looking for contributors, it's impossible to get involved with every project - however interesting they may be.

I recently came across this quote from Pieter Levels: The only way to get what you want in life is to repeatedly say no to what you don't. And this is something I want to internalise. Even though there are a lot of things that are interesting, that doesn't mean I need to be involved with all of them.

I have always done many things at the same time, and it has always seemed counter-intuitive to say no to something that I find interesting. But in the end I only have a limited amount of time, which means that I need to be much more selective with it. And besides saying no to new things, this also meant re-evaluating the things I was already spending my time on.

The first casualty of this re-evaluation was the @stoopingams instagram account. While I had only started it a year earlier, the account grew to be pretty popular and it needed attention multiple times a day. Luckily I was able to find a replacement from within the @stoopingams community so that the account can live on.

The second thing I found is that I don't want to be spending a large portion of my time on Bitcoin Cash. I've been involved in BCH since I created CashScript for my Master's thesis back in 2019. And while I spent a a lot of time on BCH, I was also active in other cryptocurrency communities like Ethereum. And in the end I'm just a lot more excited about Ethereum than I am about other projects.

Finally, I have been involved with a bunch of my own side projects, as you probably know if you're reading this blog. I started these projects for fun as I enjoy coding and building as a hobby. Even when I need a break from programming for work, I can keep programming on my side projects.

But as some of these projects grew, they sometimes started feeling more like a job than a hobby. Especially for truffle-plugin-verify I've found myself debugging other people's issues time and again, which has gotten tiring.

So I've become much more selective on the time I'm spending on my side projects as well. I've set up much stricter issue templates and I try to be very explicit about any expectations that users may have about future development (they shouldn't have any).

Armada

So come the end of 2021 I've ended my BCH work with General Protocols, I've finished my contracting engagement with Truffle, I'm only working on my personal projects for enjoyment, and I've let go of some time intensive activities like @stoopingams.

So by saying no to all those things, the remaining question is what I am saying yes to. The answer is Armada, which is the startup that I am currently working on with my friend Merwane Drai. Together we're tackling the problem of NFT discoverability by building a search engine for NFTs.

That is all I can share about Armada for now, but stay tuned for an exciting 2022. We have a bunch of great things in store that we can hopefully share soon.

📈 2022

In 2021 I helped build important new products for Bitcoin Cash and Ethereum. I got started with collecting NFTs and creating generative art. I added significant new features to my open source tools and apps which have seen tremendous growth.

While I have started to spend less time on my open source side projects, I do want to make sure they stay relevant. I hope to attract more community contributors to get involved with these projects so that I can shift my more time towards guiding them instead of developing myself.

In 2021 I had to step back and re-evaluate what I wanted to do, but by the end of the year I was able to set my priorities straight. I plan on going into 2022 with more focus and I am excited to build Armada together with Merwane.

Since the start of 2021, Non-Fungible Tokens (NFTs) have become increasingly popular inside and outside of existing crypto communities. Trading volumes for NFTs have skyrocketed and a bunch of new communities have formed around them.

Most NFTs are traded on marketplaces such as OpenSea or Rarible. The main value of these marketplaces lies in their big orderbooks of listings and bids to choose from. This allows anyone to buy and sell NFTs from anyone else without needing to actually interact with their counterparty.

This works great when you want to buy and sell your NFTs for ETH or other cryptocurrencies. But it is lacking when you want to trade NFTs for other NFTs or when you want to negotiate a deal with your counterparty.

So today we're looking into platforms that are specifically tailored for trading NFTs in a peer-to-peer (P2P) manner rather than using a centralised marketplace.

What platforms exist in 2021?

Three popular P2P trading platforms are NFTTrader, Sudoswap and Swap.kiwi. All three were created in this past year so the ecosystem is still young and we should expect more platforms to be developed in the future.

NFTTrader

NFTTrader was the first P2P NFT trading platform as it was launched in January of 2021 by a team of four founders. The team created their own custom asset-swap smart contracts that allows users to swap any combination of ERC20, ERC721 and ERC1155 tokens, as well as ETH.

Sudoswap

Sudoswap was created by well-known developer 0xmons in April of 2021. And while NFTTrader created their own smart contracts, Sudoswap uses the open-source 0x protocol to create and settle swaps between any combination of ERC20, ERC721 and ERC1155 tokens.

Swap.kiwi

Swap.kiwi is the youngest platform of the bunch as it was created in June of 2021 by ape punk niftynaut. They developed their own smart contracts to execute swaps between any combination of ERC721 and ETH.

How do the platforms compare?

To compare the different platforms, I asked snooplyin42 to help out. Together we sat down and swapped 2 for 2 BASTARD GAN PUNKS NFTs on each of the platforms and discussed the pros and cons of each platform.

Features & functionality

In its essence these three platforms offer the same basic functionality. Namely, they allow you to swap baskets of NFTs and fungible tokens with a counterparty. But the supported assets are slightly different.

NFTTrader has the broadest asset support as it allows baskets of any ERC20, ERC721, ERC1155 or ETH tokens. Sudoswap also supports ERC20, ERC721 and ERC1155, but lacks support for the native ETH token (although WETH can be used). Swap.kiwi has the smallest list of supported assets since it only supports ERC721 and ETH.

Sudoswap boasts two additional features that the other two platforms lack. First, it allows you to leave the counterparty blank, which means that anyone can fill the order. This is particularly useful when trading your NFTs for fungible tokens.

Second, it allows you to set an expiry date/time. When this date/time is reached, the proposed swap automatically becomes invalid. This gives you the option to let a swap expire rather than having to send an on-chain transaction to cancel the swap. This limits the downside when the counterparty decides not to go through with a swap.

However, one important feature limitation of Sudoswap is that it's impossible to create swaps from multisig wallets or smart contract wallets like Argent. NFTTrader and Swap.kiwi do fully support multisig wallets (and smart contract wallets).

Overall website & UI

The Sudoswap UI has a sort of vapourwave windows 95 look. There are plenty of people - especially within the crypto space - that enjoy this kind of aesthetic. At the same time it can also be a barrier to entry for people more used to a regular "web2" aesthetic. But while the aesthetic may be an acquired taste, the functionality is laid out clearly and it's easy to find what you're looking for.

Swap.kiwi, on the other hand, has a very clean and much more approachable UI than the other two. It is laser-focused on only offering the swap functionality in a single page, without any secondary features. This makes the app very accessible and familiar, especially for web2 users. At the same time, it could be good to offer more information or explanation about the app itself.

While the UIs of Sudoswap and Swap.kiwi are mainly centred around the swap features, NFTTrader has a lot more going on. On one hand, this means they include a lot more useful information and explanations. But it also means that it includes some less relevant features, such as leaderboards, gamification and their own NFTs.

All platforms have some small UI bugs and weird quirks that still need to be polished out. As an example, each of the platforms seemed to have some trouble with updating the UI after certain blockchain actions were executed (e.g. approval or accept swap). But that is a notorious problem in blockchain development in general.

Among the platforms, we ran into the most UI quirks with Sudoswap, while NFTTrader had the most polished experience, albeit still not without quirks. This makes sense as Sudoswap was recently overhauled while NFTTrader has been able to mature since its January launch.

Swap flow & UX

While all three platforms achieve similar things, the swap process and UX is drastically different among the platforms.

Sudoswap

On Sudoswap you can propose a new swap by choosing the "create swap" option. You can then select the tokens they are putting up for the swap and the tokens they want to get in return.

When selecting which tokens to send, it automatically displays the NFTs that you have in your wallet, but any kind of search functionality is lacking here, so scrolling through a large wallet can get very tedious.

If you can't find the tokens you're looking for, you can use the included "form" to add other tokens. The form requires you to copy-paste a contract address + token ID, so this process is only really suited to advanced users.

When selecting which NFTs to receive, you can choose from a default list of NFT collections, where you have to specify which token ID you want to receive. While some of the bigger collections are included, some very notable collections are missing, such as Cool Cats or CrypToadz. For these contracts you have to use the earlier mentioned form, which again requires you to look up and paste the token's contract address, which is advanced functionality.

Once you're happy with your swap, you have to send an approval transaction for every separate collection and you can optionally specify values for the counterparty address and expiry date, and finally click "create swap". From there you are prompted to sign a message through your wallet, after which a swap link is created which can be shared with your counterparty.

If you specified a counterparty address, then they can also find it under the "your swaps" section of the website. After sending the required approval transactions they can accept the swap with a transaction.

NFTTrader

Similar to Sudoswap, NFTTrader allows you to specify a list of tokens you want to send and a list of tokens you want to receive. Unlike Sudoswap, NFTTrader has a more mature selection interface with an easy-to-use search functionality.

But while Sudoswap allows you to add custom tokens through the "form", NFTTrader is limited to the tokens that are enabled in the UI. If your token is not in the list you'll need to contact the NFTTrader team to have it added. Luckily the team is responsive in doing so.

Also unlike Sudoswap, with NFTTrader you have to specify a counterparty address. But the great thing about that is that you can then select the NFTs you want to receive by browsing your counterparty's wallet, rather than having to copy-paste token IDs.

Once you're happy with your swap, you have to send an approval transaction for every separate collection, after which you click "pay now". This prompts you to send a transaction, after which a swap link is created.

Similar to Sudoswap, you can either send that swap link to your counterparty or they can find it under their "my swaps" section. After sending the required approval transactions the counterparty can accept the swap with a final transaction.

Swap.kiwi

Of the three platforms, Swap.kiwi definitely has the most unorthodox UX. Rather than proposing a full swap you can only select the NFTs that you're putting up for the trade as well as the counterparty's address. After approving the assets they then send an initial transaction to start the trade.

The counterparty can then see this "half swap" under their "open swaps" section, where they can add the NFTs that they are putting up. After approving those assets they can create a full swap by sending another transaction.

The initial swap creator then has to find the swap under "open swaps" and after inspecting the swap terms, they can finally accept the swap with a final transaction. In total this flow requires three transactions, and both parties have to select the NFTs they're putting up for the trade.

The good thing about this kind of flow is that both parties have full control over the assets they select for the swap, which makes scamming your counterparty slightly more difficult. But the problem with it is that it's fundamentally not how people think about P2P swaps.

Because the maker and the taker are usually in contact through some other means to negotiate a fair trade before settling it on-chain, the maker can propose the full trade, rather than having these on-chain "negotiation" steps.

Gas cost & fees

When looking at gas efficiency and fees, Sudoswap comes out miles ahead. Because the platform uses well-established and gas-efficient contracts (through 0x) and they only require a single transaction, the total gas required for the swap is around a third of that of the other two platforms. And for the maker, Sudoswap doesn't cost any gas at all.

Additionally, Sudoswap is the only platform to include an expiry date for a swap, meaning that it's possible to let a swap expire rather than cancelling it through an on-chain transaction. The other two platforms do not have that functionality, so if you want to cancel a swap, you'll incur additional transaction fees.

Finally, both NFTTrader and Swap.kiwi include a flat platform fee to both the maker and the taker, while Sudoswap charges no fees at all.

Below is a comparison of the total fees paid for a 2-for-2 NFT swap at different gas price levels. As can be seen, the difference between NFTTrader and Swap.kiwi is not as significant, although NFTTrader is slightly more expensive - despite Swap.kiwi needing three transactions.

But the difference between Sudoswap and the others is immense, as it is at least three times cheaper at every gas level, while it's even six times cheaper than NFTTrader when gas is at 10 gwei due to the platform fees.

Popularity & usage

To measure popularity of each of the platforms we look at the number of trades in the past 30 days (as of 30 Nov 2021). In doing so it's important to make a distinction between swaps, where both sides include NFTs, and sales, where only a single side includes NFTs. Note that Swap.kiwi only supports swaps.

To get this data I put together a script that retrieves the transaction data from the blockchain and classifies the different trades as either a swap or a sale. Another important metric is the value of those trades. So besides the classification of trades, the script also estimates their value. Note that both sides of the trade are included in the total value.

For ETH and ERC20 tokens it uses the latest USD price, while for NFTs it calculates the recent average sale price. This estimation is not perfect since the crypto and NFT markets are very volatile, so the current price may not accurately reflect the price at the time of the trade. Additionally, the estimate may not accurately reflect the price of 1/1 NFTs or shared collections like Art Blocks or Foundation.

As can be seen in the table below, NFTTrader is leading in number of monthly swaps and sales, with Sudoswap having about half the sales and 2/3rd the swaps that NFTTrader has. Swap.kiwi on the other hand doesn't come close to the other two, as it only has less than 20% of NFTTrader's monthly swaps.

But when looking at the value of the trades, we see a different story. While Swap.kiwi has a much smaller number of swaps, the average value is more than twice as high. This seems to indicate that Swap.kiwi is the preferred platform for higher value trades.

Another interesting observation is the difference between swaps and sales. The total number of sales across the platforms is more than twice the total number of swaps and the total dollar volume of sales is almost five times the volume of swaps, showing that sales are still the main use case for these platforms.

Smart contracts & audits

NFTTrader and Swap.kiwi developed their own contracts, while Sudoswap uses the open source 0x contracts. The 0x contracts were audited by ConsenSys Diligence, Swap.kiwi was audited by Hacken.io, and NFTTrader has received review from Carl Farterson. All contracts are available on Etherscan: NFTTrader, 0x, Swap.kiwi. The audits are also available online: NFTTrader, 0x, Swap.kiwi.

Verdict

All three platforms are designed to trade baskets of assets in a peer-to-peer fashion, but Sudoswap and NFTTrader offer a more diverse set of assets than Swap.kiwi. In addition, Sudoswap has some interesting extra swap features that do not exist on the other two platforms. However, Sudoswap does not support multisig wallets.

The swap UX of Sudoswap and NFTTrader is very similar. The main differences are in NFTTrader having a more polished and accessible experience and Sudoswap only requiring a single transaction. Swap.kiwi employs a very different swap UX that requires a total of three transactions.

Despite requiring three transactions, Swap.kiwi comes out slightly ahead of NFTTrader in terms of gas and platform fees, but neither is a match for the gas efficiency of Sudoswap, which is at least three times cheaper to use than the other platforms.

NFTTrader is the most mature product of the bunch and has the most active users, but Sudoswap is gaining fast after their overhaul in October. Swap.kiwi is lagging behind in terms of usage, but is also the youngest of the three platforms.

And while NFTTrader is a more polished product, Sudoswap comes out as the clear winner in this comparison due to its added functionality and vastly superior cost effectiveness.

Cover art by Kajal Baliyan

2020 was a weird year. COVID changed the dynamics of life around the world. Governments enforced lockdowns and business had to close. Stock markets crashed, only to bounce back spectacularly. Remote working became the norm, while travel completely shut down.

Much of 2020 was about figuring out how to live with these new dynamics. Working from home, eating in, learning to have fun without going out. When the weather was nice, meeting friends in the park was a good alternative, but in winter, that doesn't sound very appealing.

Despite everything going on in the world, I feel like my year was pretty good. I didn't travel as much as I would have liked, but with a beautiful house by the canals, I did get the unique experience of Amsterdam without any tourists.

✍️ Writing

Around March and April I had a bit more time on my hands due to COVID. So I used that extra time to catch up on a few posts that I still wanted to write. Most notably I finished my Year in Review for 2019 - about 3 months late.

Around that time I also revisited some old love2d gamedev projects, where I spent a lot of time debugging and automating the web build of my game. This led me to publish a guide on building love2d games for the browser so that others in the same situation hopefully will have an easier time.

While I had several articles in draft for a while, during the rest of the year the only other article I was able to finish was Unlimited ERC20 allowances considered harmful. This was an article that I wanted to write since the end of 2019 when I initially created revoke.cash, but it took me a long time of on-and-off writing to finish it.

So I didn't write a lot this year, but I am fine with that. There are plenty of other ways I am sharing my knowledge, such as conferences, open source code, or StackExchange. And in comparison writing a high quality article takes up much more time. So it is good to be selective with what I write and only publish something when it really adds to the conversation.

🏠 Staying Home

In my 2019 Year in Review I had a section dedicated to travelling as I had flown around the world twice that year. So I figured with much of the world in lockdown, it'd make sense to have a similar section titled Staying Home this time around.

My girlfriend and I returned to Amsterdam around the end of 2019. We had some trouble adjusting to the "regular" life back home, as well as the cold winter weather. But after a while we started settling in and we found a new rhythm here.

We were still renting our old student apartment, so we quickly had to start looking for a new home (student leases automatically end six months after graduation). The house search was challenging, but we ended up with a beautiful apartment on Amsterdam's innermost canal.

After visiting London in the final week of February I got sick, and shortly after my girlfriend got sick as well. Even though COVID-19 was gaining momentum, I wasn't able to get a test back then, so I'm not sure if I had COVID or just a regular flu, but to err on the safe side we decided to stay inside for several weeks.

By the time we got out of quarantine, the rest of the country had gone into it. Many stores, gyms and theatres closed and restaurants had to switch to delivery only. Somehow the months of lockdown flew by in an instant, while also lasting forever. Time can be funny like that.

By summer, most lockdowns were lifted, so we decided to take a much needed break in the beautiful Italian town of Carloforte (population 6000). This small holiday made us realise what we had been missing the past months so once back we planned another much larger trip to visit our friends in Curaçao for a month.

Being there brought us back to the nomad life that we lived in 2019 and made us realise that we don't want to stay in Amsterdam forever. We'll likely still be here for a little while longer, as we do have a lot of friends and family that we like having close. But the goal is to be on a plane again sooner rather than later.

🎙 Events

Because of COVID-19, most in-person events I wanted to attend were cancelled or moved to the virtual space. I'm not a big fan of virtual events, but given the situation I decided to give them a try. And I still don't think they're a replacement for real in-person meetups. But I did have a pretty good time at the virtual events I attended.

ETHLondon

Before the world went into lockdown, I was able to go to the ETHLondon hackathon. Over there I teamed up with my girlfriend and some of our friends for an intense weekend of hacking up Radical.domains.

Radical Domains is an innovative ownership model for ENS domains that is based on Harberger taxes. Under this system ENS names are always for sale at a price set by its owner, and the owner pays a percentage-based tax/rent over this price. This incentivises productive use of the domain name and disincentivises the hoarding or "squatting" of domains.

HackMoney

Since all in-person events were cancelled I decided to give virtual hackathons a try. I initially expected that I wouldn't enjoy it as much, but I ended up with a great team and we had a lot of fun implementing LiquiDeFi, a contract that pools user's funds to execute liquidations on popular DeFi platforms such as Aave.

We ended up being chosen as one of the ten winners (or finalists) of the hackathons. After the hackathon we made some attempts to continue on with the project, including applying to Gitcoin's KERNEL program. In the end we didn't end up having the resources to pursue this project.

BCHDEVCON 3

The first hackathon I ever participated in was BCHDEVCON Amsterdam, organised by Eléonore Blanc back in 2018. So when she was organising the next iteration of the BCHDEVCON hackathon this September I knew that I could not miss it.

I teamed up with my UI/UX designer friend Jenny and together we built CashScript Playground, an online IDE for writing CashScript contracts, with a generated UI to immediately interact with the contracts. It was inspired by Ethereum's Remix IDE, but it is much more basic.

TruffleCon 2020

Because TruffleCon was moved to the virtual space, I thought about skipping it this year. But ultimately I decided that it would be nice to give a short talk about truffle-plugin-verify, since I hadn't done a public walk through of the plugin yet.

While there were some interesting talks at TruffleCon 2020, the talks are never the main reason to go to any conference. And it is always difficult to really connect with people in virtual events. I did enjoy it, but I also hope we'll see an in-person TruffleCon 2021.

📸 @stoopingams

In 2019 I visited my friend Jenny in New York, where she introduced me to the @stoopingnyc instagram account. This account posts pictures of furniture that NYC residents put outside so that others can pick it up and give it new life. People who spot something send it to the maintainers of this account and they post the best items.

I started looking for similar accounts in Amsterdam, but when I couldn't find any I decided to start @stoopingams in April of 2020. At first it was just friends and family submitting photos, but it quickly grew to 1000+ followers.

Meanwhile the @stoopingnyc account exploded to more than 100k followers, and news outlets even picked up on it. Several outlets also reached out to me for some segments, so in 2020 @stoopingams was featured in Bobblehaus, NBC's Today and The Wall Street Journal.

It has been really nice to see a kind of community developing around the account. There are people that regularly submit their finds and people share some amazing stories as well. Overall it has been a great way to get out of my software engineering bubble and get involved with something completely different.

⛓ Cryptocurrency

As 2020 has come to an end it looks like cryptocurrency is heading into a new bull market. BTC is at a new all time high and we've seen DeFi coins like AAVE and LINK increase more than tenfold in the past year.

In 2020, Aave and Uniswap launched their v2, while other projects like Yearn and Ren had their mainnet launch this year as well. DeFi is expanding to other popular chains too with projects such as Atomic Odds on BTC and AnyHedge/Detoken on BCH.

Infrastructure development has also continued to flourish. Ethereum 2.0 launched its beacon chain and BTC is gearing up for its Taproot upgrade. Funding for open source projects has increased greatly. The latest Gitcoin Grants round raised more than a million USD for open source projects and FlipStarter raised a similar amount in 2020.

AnyHedge

In 2019 I built CashScript, a smart contract language and SDK for Bitcoin Cash. Because of this, I was asked by General Protocols to join their team in developing AnyHedge, the first DeFi project on Bitcoin Cash. They raised funding in May of this year, and I joined them shortly after.

AnyHedge can be seen as a risk-trading contract. Two parties can enter a contract where one party locks in the USD value of their BCH, while the other party gets leveraged exposure to the price movement of their BCH.

The smart contracts for AnyHedge are written in CashScript, so as part of the work at General Protocols I maintain CashScript, as well as contribute to other fundamental libraries such as electrum-cash. Besides this I work on the open source AnyHedge library and other parts of the AnyHedge stack.

The AnyHedge library and contracts have been available for several months, but on 30 December 2020 we also launched our first integration into the non-custodial Detoken exchange. This allows regular users to use these contracts and get stability or leverage on their BCH.

CashScript

One great thing about working on AnyHedge is that all of a sudden I was able to eat my own dog food with CashScript. By actually using CashScript for a non-trivial project myself, I discovered a lot of things that required improvement.

So over the course of 2020 I rolled out two major (and plenty minor) updates. Most importantly I removed the dependency on BITBOX, which has not been maintained for a while. Instead CashScript can now be used with a number of different libraries, while implementing adapters for other libraries is very easy.

Besides this I added support for OP_REVERSEBYTES and bitwise operations. I also completely refactored the contract instantiation API and the transaction sending API. Finally I made a plethora of quality of life improvements and tweaks, bug fixes and compiler optimisations.

Truffle

If you've read my previous year in review posts, you know that I am a big fan of the Truffle suite of Ethereum developer tools. TruffleCon 2018 was the first conference I ever spoke at, and I returned for TruffleCon 2019 and 2020. I wrote several libraries that integrate with Truffle, and use it in my own ETH projects as well.

So when Truffle reached out in December for some contracting work I was happy to accept the gig. In the coming months I'll be working with the Truffle team in a part time contracting setting to help with the Truffle+Filecoin integration.

This integration will allow developers to persist their dapp frontend on IPFS/Filecoin and spin up a local version of IPFS and the Filecoin blockchain for testing purposes. Part of the integration is an overhaul to the Truffle plugin system, something I am already quite familiar with through my work on truffle-plugin-verify.

truffle-plugin-verify

While the initial release of truffle-plugin-verify was in 2019, this year brought some big improvements to the project. The most important update was v0.5.0, which was a complete overhaul of the plugin's functionality.

In earlier versions, the plugin flattened a contract's source file by concatenating all imported source files. The result was a huge source file that was difficult to navigate. So v0.5.0 uses so-called Standard Input JSON, in which the contents of all relevant files are stored in a structured JSON file. This results in Etherscan displaying all these files separately, making the verified code much easier to navigate.

The second important update is that besides Etherscan, the plugin now also supports source code verification for BscScan. BscScan is a block explorer similar to Etherscan, but for Binance Smart Chain (BSC) instead of Ethereum. So if you're writing smart contracts for BSC, you can use truffle-plugin-verify for source code verification.

revoke.cash

Revoke.cash is a website that shows you a list of your outstanding ERC20 allowances, allowing you to re-evaluate them and revoke them if you no longer need them. I wrote an in-depth article that outlines the reasons why you'd want to do this.

Revoke.cash is also not a new project. But like truffle-plugin-verify, it did see some important updates in 2020. Notable changes are ENS support, token icons, a home-made logo, and design improvements.

Another notable update was integrating the Kleros T2CR, an on-chain curated registry of tokens. New tokens are added to this registry through a fully decentralised process. By using this registry, only registered tokens are displayed in revoke.cash's UI, while unregistered tokens are hidden behind a checkbox.

🐙 Open Source

When I reflected on my open source projects in 2019, one thing I noted is that I hadn't made any real contributions to other projects, while I had received many on my own projects. So I decided that I wanted to contribute to more projects in 2020. And I did.

It's always easier to think of important missing features or other pain points if you're an actual user of the project yourself. Which is why the contributions I made were all to libraries and tools that I use in my own work.

The Bitcoin Cash upgrade in May included a new opcode, OP_REVERSEBYTES. Because I wanted to support this new functionality in CashScript, I needed underlying libraries to support it as well. So to expedite that process I raised PRs to bitcore-lib-cash and libauth adding support for the new opcode.

As part of my work with General Protocols, I have been working with the Electrum protocol a lot, so when Chris Troutner wanted to integrate Electrum functionality into his FullStack.cash offering, I was happy to help out and raise some PRs as well.

Earlier in the year I also wanted to get a bit more familiar with the Truffle codebase, so I picked up a few small issues and raised PRs for them. Turns out that was a good call, since it means I won't need to spend too much time getting familiar with Truffle's code for the upcoming Filecoin integration.

My own open source projects have also continued to gain popularity. Both truffle-assertions and truffle-plugin-verify passed the 100 star milestone on GitHub this year. My NPM packages now get a combined 25k+ monthly downloads, almost doubling last year's stats and especially truffle-plugin-verify has seen a big uptick in users.

Of course no open source project is ever a one-man job, so I want to thank everyone who contributed to these projects in 2020, whether that is by opening issues, raising PRs or maintaining underlying libraries.

For truffle-plugin-verify I want to particularly thank xzjcool for implementing BscScan verification into truffle-plugin-verify and the entire Etherscan team (but especially Enigmatic331) for being responsive and solving issues on the Etherscan side. I also want to thank chriseth for being available to help out with any Solidity compilation quirks that come up now and then.

For CashScript I want to thank Michael McLaughlin for custom UTXO selection, Andre Cabrera for browser support, and 2qx for regtest support. I also want to thank Dagur Valberg Johansson and Shomari Prince for their feedback and bug reports.

Overall I am happy with the direction that my open source projects are headed, and it is motivating to see usage rising across the board.

2021

In 2020 I did a lot of work on my open source projects and I contributed to important open source libraries that I depend on as well. I joined General Protocols to work on the first iteration of DeFi apps on BCH. AnyHedge launched in the final days of 2020 and has seen almost $1M in volume in its first two weeks.

In the coming year I look forward to keep building on AnyHedge, my personal projects and other freelancing projects. I'm planning to go to EthCC in Paris in April, so I hope 2021 will see a resurgence of in-person events and travel as well.

The latest big thing in Ethereum is Decentralised Finance (DeFi). Central applications of DeFi are lending, staking and trading ERC20 tokens. To use ERC20 tokens in DeFi protocols such as Uniswap, Aave or Yearn you have to grant the dapp permission to spend tokens on your behalf - known as an ERC20 allowance. These allowances are integral to the functioning of DeFi platforms, but can be dangerous if left unchecked.

Note: this post specifically talks about ERC20 allowances, but it also applies to NFTs.

Why are ERC20 allowances necessary?

With Ethereum's native ETH token it is possible to call a smart contract function and send ETH to the contract at the same time. This is done using so-called payable functions. But because ERC20 tokens are smart contracts themselves, there is no way to directly send tokens to a smart contract while also calling one of its functions.

Instead, the ERC20 standard allows smart contracts to transfer tokens on behalf of users - with the transferFrom() function. To do so, the user needs to allow the smart contract to transfer those tokens on their behalf.

This way, a user can "deposit" tokens into a smart contract, and at the same time, the smart contract can update its state to reflect the deposit. In contrast, if you just send ERC20 tokens to the contract, the contract cannot update its state (e.g. to credit the deposit to your account).

As an example, if you want to "deposit" DAI into Aave to earn interest, you need to first allow the Aave contract to take some DAI from your wallet. Then you call a smart contract function on the Aave contract where you specify how much DAI you want to deposit. The Aave contract then takes exactly that amount from your wallet using the transferFrom() function and credits you with the same amount of aDAI tokens.

Why are unlimited ERC20 allowances harmful?

When depositing a specific amount (say 100 DAI) into a contract, you can choose to set an allowance of exactly that amount. But instead, many apps instead request an unlimited allowance from the user.

This offers a superior user experience because the user does not need to approve a new allowance every time they want to deposit tokens. By setting up an unlimited allowance, the user just needs to approve it once, and not repeat the process for subsequent deposits.

However, this setup comes with significant drawbacks. As we know, bugs can exist and exploits can happen even in established projects. And by giving these platforms an unlimited allowance, you do not only expose your deposited funds to these risks, but also the tokens that you're holding "safely" in your wallet.

I first talked about this with Paul Berg at Devcon 5, where he gave a presentation about precisely the issues discussed in this article. While developing Sablier, Paul found (and fixed!) a bug in his smart contracts, where not only the deposited DAI ($100) were at risk, but also all DAI in the testers' wallets ($10k)!

Real world risks

For a long time the risk of unlimited allowances was largely theoretical, and Paul's Sablier bug was fixed before the platform went into production. Back then there hadn't been any exploits that took advantage of ERC20 allowances, but it was bound to happen as platforms kept using unlimited allowances.

And over the past years we have seen several such exploits.

Bug exploits

In early 2020, Bancor experienced a bug that put users' funds at risk. The function that executes the ERC20 transferFrom() function was accidentally made public (rather than private to the contract), which allowed anyone to execute it and drain the users' wallets. Bancor performed a white-hat hack of the contract to contain the damage and returned the funds back to users.

Another high profile bug exploit was the Furucombo hack in February 2021, where a bug in the Furucombo protocol enabled a hacker to drain the wallets of people who gave an allowance to Furucombo, even if they didn't have any funds deposited into the contract directly.

Malicious projects

While bugs can happen even in reputable and legitimate projects, there have also been cases where the project itself was malicious. During 2020's DeFi summer, people were jumping at every new food-themed DeFi fork, which included some outright scams. And even if people tried to limit their risk by only depositing small amounts, funds in their wallets were still at risk because of unlimited ERC20 allowances.

ZenGo reported one such exploit in a project called UniCats. People could deposit their Uniswap (UNI) tokens to farm MEOW tokens (you can't make this up). But to do the deposit, they had to grant an unlimited allowance. When the project inevitably rug-pulled, the scammers not only took the deposited funds, but also all UNI tokens that users had in their wallets.

Another such case happened with a project called Degen Money, which used a slightly less sophisticated (but not less effective) approach. Rather than developing their own smart contract, they created a frontend that made two approval transactions. One to a functioning contract, and one to a completely different address.

Because many people do not specifically check the contract addresses, this allowed the attackers to drain users' wallets.

What about hardware wallets?

In general, hardware wallets (such as the Ledger Nano X) are much safer than mobile or browser-based wallets. The reason for this is that the private keys that control the funds are securely stored on the hardware wallet and never leave the device. So by using a hardware wallet you ensure that no one can steal your private keys.

The problem with ERC20 allowances though, is that no one needs to steal your private keys to take the tokens from your wallet. And because of that, hardware wallets offer no protection whatsoever to the exploits discussed in this article.

It is still good practice to use a hardware wallet because they do protect you against a range of other possible exploits. But you need to be aware that they do not protect against allowance exploits or many other smart contract exploits.

What can dapp developers do?

In his talk at Devcon, Paul mentioned several possible solutions to the unlimited allowance problem, which all have different strengths and drawbacks. The most practical of those solutions is using the approve-spend pattern. In this pattern you only request the user to approve the exact amount that they want to use at that moment, rather than an unlimited amount.

This is a worse user experience since the user needs to send a new approval transaction every time they want to send a transaction, rather than doing one single approval. This also has the added drawback that it costs more in transaction fees, which can be especially troublesome when fees rise like they did last summer.

So a better option is to offer the choice to users where they can either choose to approve only what they need to spend at the time, or they can approve a much larger amount if they intend to do more transactions in the near future. This strategy is already employed by several projects, such as Zapper.fi and Curve.fi.

An alternative solution to mitigate transaction costs is adopting EIP2612 (permit). This standard enables users to sign a message to set their allowance (which is free), rather than having to send a transaction to do so. The developer ecosystem around EIP2612 is small, but it is growing rapidly and projects such as Uniswap are using it for their lending provider tokens.

What can users do?

Since ERC20 allowances are integral to the functioning of many smart contracts, it is not an option to stop approving allowances altogether. But where possible, try to avoid unlimited allowances.

People are more aware of this issue than a year ago, so some dapps offer the option to only approve the amount you're spending at the moment, but most apps still don't. Even then, advanced users can lower their allowance through Metamask's interface.

When you're using a dapp try to consider if you're going to be using this dapp a lot and you trust the project (unlimited allowance), or if you'll use dapp infrequently or you do not trust the project (smaller allowances). In either case it is also a good practice to review your outstanding allowances periodically (say every month), and revoke those that you're not actively using any more.

To inspect and revoke these allowances, I developed a tool called Revoke.cash. It gives an overview of an address' token balances and corresponding allowances. Allowances can then easily be revoked or lowered.

How is revoking different from disconnecting MetaMask?

MetaMask has an option to disconnect any accounts that you previously connected to a website. Some people think that using this disconnect button will protect them from exploits. This is not the case.

Disconnecting MetaMask does not do anything to protect you from allowance exploits - or most other exploits. The only thing that you achieve when disconnecting MetaMask from a website is that that website cannot see your address any more.

Conclusions

Allowances are necessary for the functioning of many decentralised applications, but at the same time unlimited allowances are generally harmful to security. We've seen several exploits in the past two years that take advantage of ERC20 allowances, and the awareness of the issue is much higher today than it was in 2019. There are a few things you can do as a user to mitigate the discussed risks, including periodically reviewing and revoking outstanding allowances.

I wrote my first year review in 2018 because I felt that a lot had happened and I wanted to reflect. And I feel the same about 2019. A lot changed in my life as I shifted from being a student to working in the cryptocurrency space. In this article I reflect on these changes.

I'm publishing this article rather late, given that we're already in the second quarter of 2020. I didn't manage to complete the article early in the year, but it is never too late to look back and reflect. Even three months later. I try to keep the focus on 2019, leaving events of the past three months for next year's reflection.

✍️ Writing

Last year I noted how my writing had slowed down in 2018 with just three articles. And this year my writing has not been more productive. But while I saw it as a negative point last year, I'm actually quite content with my writing the past year. I've decided that it's alright like this. There's no need to pump out new articles every month, and it's fine to take some time.

Last year I listed three articles that were still in the pipeline for 2019. And guess what? None of them got published. But I realise why. At first I wanted to write these articles just to help out people with the same problems as me. But while I was writing them, I realised that these posts would not be publish-and-forget.

They would need support and updates after publishing. And I was not interested enough in the topics to justify spending that time. So instead I focused on topics that did interest me enough to keep them up to date.

This led me to publish three different articles centred around smart contracts.

• Automatically verify Truffle smart contracts on Etherscan
• Creating Truffle plugins
• Smart Contracts on Ethereum, Bitcoin and Bitcoin Cash

This time around I won't be listing the articles that I might or might not publish in 2020. I've learned from my mistakes of last year. But if you're still interested to read about anything in particular, let me know in the comments below.

🎓 Graduation

I've been a student for most of my adult life. I started my Bachelor's degree in Computer Science when I was seventeen, and completed it in 2018. I immediately continued with a Master's degree in Software Engineering.

I had some doubts going into the Master's program, as I'd rather spend more time on actual software engineering rather than lectures. But the degree I chose to pursue is very practical and is a only one-year program, so I decided to go for it.

Because the program has a practical focus, part of the work is doing a project at a company and write a thesis on it. I chose to do my project at Bitcoin.com, where I joined Gabriel Cardona's team to create a high-level smart contract language for Bitcoin Cash, called CashScript.

The project and thesis were well-received by the company and the graduation board. So after defending my thesis in late August I finished the project with a 9/10. My supervisor urged me to publish a paper, as I had done in 2018 with my BSc thesis. While this did interest me, the months that followed proved to be filled with many other exciting things. So in the end I decided to forgo another publication.

⛓ Blockchain & Cryptocurrency

As with 2018, this year was filled to the brim with blockchain and cryptocurrency projects. Besides my biggest project CashScript, I created truffle-plugin-verify and revoke.cash, and maintained my previous project, truffle-assertions. I also attended cryptocurrency events and was featured in several publications.

CashScript

In early April I flew over to Tokyo to work on CashScript at the Bitcoin.com office. In the months that followed I researched Bitcoin, Bitcoin Cash and Ethereum, and I did a deep dive into Bitcoin Script, the VM that powers BTC and BCH transactions.

CashScript's syntax was inspired by Ethereum's Solidity to allow for more collaboration between the Ethereum and Bitcoin Cash communities. The CashScript SDK was also inspired by several Ethereum projects, including Truffle and web3.js.

Since then CashScript has greatly simplified smart contract development in Bitcoin Cash, and has made complex techniques like covenants accessible. The full compiler stack as well as the SDK were implemented using TypeScript for strong integration within Node.js and browser applications.

If you're interested in learning more about the differences in smart contracts on Bitcoin, Bitcoin Cash and Ethereum and where CashScript fits in, read my article Smart contracts on Ethereum, Bitcoin and Bitcoin Cash.

truffle-plugin-verify

Around the same time I started working on CashScript I also created one of the first widely used Truffle plugins: truffle-plugin-verify. The plugin allows you to take any smart contract in your Truffle projects and submit its source code to Etherscan for verification. Read more about this process in my article Automatically verify Truffle smart contracts on Etherscan

Before this plugin, source code verification was only possible through a convoluted process that forced you to use Remix for contract deployment. And since Truffle has built-in functionality for contract compilation and deployment it would be unfortunate to throw that out of the window.

So instead truffle-plugin-verify adds a single command to the Truffle CLI that allows you to seamlessly verify the source code of any of the contracts deployed using Truffle. The plugin just needs to be set up with an Etherscan API key after which it can be used.

truffle run verify SimpleStorage --network goerli

Truffle University

The plugin slowly began to gain traction, but it was one of the few Truffle plugins that was actually being used. Since there weren't many resources and guides on how to create Truffle plugins, I decided to contribute some of my own knowledge.

I was asked to be a guest lecturer on Truffle University, a course for learning Ethereum smart contract development. I gave a hands-on workshop on Truffle plugin development, where we went through the entire process of developing a non-trivial Truffle plugin. The code for this workshop can be found on GitHub, and I later wrote an article about the same subject.

revoke.cash

Later on in the year at Devcon V in Osaka, I finally met Paul Berg in person after previously having contact online. We talked a lot and one thing that stuck with me was the risk of ERC20 allowances in DeFi.

Many DeFi applications - like Uniswap, Compound or Sablier - need to spend ERC20 tokens on the user's behalf. This is necessary for the functioning of these platforms, but could be dangerous if left unchecked.

If a bug is found in one of the smart contracts that has an active allowance, tokens can be taken from the "safety" of your wallet. So while these allowances are necessary when using the DeFi applications, but it is good practice to revoke outstanding allowances when you're not using them. Revoke.cash gives you an overview of all outstanding ERC20 allowances so they can be revoked.

🐙 Open Source

Almost all of my personal and professional projects are open source. Especially in cryptocurrency open-source software is important. The software can be dealing with large amounts of funds and even users' keys (in case of wallets), so this code should be publicly auditable.

My open source projects have increased in popularity, with CashScript and truffle-plugin-verify getting close to 50 GitHub stars within the year and truffle-assertions doubling in stars. But more impressive is the fact that my NPM packages now get a combined 15k+ monthly downloads (mostly truffle-assertions). And that they're being used in big open source projects, such as Gnosis, Kyber and Ren.

All projects also attracted outside contributors, so I'd like to thank Andre Cabrera and Gabriel Cardona for contributing to CashScript, Leon Prouger for contributing to truffle-assertions and Jens Jørdre, Kata Choi, Vincent Au, Sean Casey and Tim Coulter for contributing to truffle-plugin-verify.

But while my own projects grew and many people contributed, I contributed less to other open source projects than I did in 2018. I did help out with some things on BITBOX, Kickback and Atomic Loans and I picked up my first Gitcoin bounty. Nonetheless, I want to contribute to some more open source projects in 2020.

🎙 Events

The first time I spoke at a conference was in 2018 at TruffleCon. And a month later I participated won my first hackathon at the Amsterdam BCH Hackathon. I enjoyed these events a lot, so it's unsurprising that I continued this trend throughout 2019.

Just before I left for Tokyo, I went to EthCC in Paris, followed by ETHParis. The company I worked for at the time has housing in Paris so I was able to stay there the entire week 🎉! I repeated the talk I gave at TruffleCon 2018 in front of a new audience, and it was interesting to see the difference in reactions.

At ETHParis I hacked with people I had met at previous events, and we managed to win the JPMorgan Quorum prize. While I enjoyed the hackathon, we were too focused on winning a specific prize, rather than building something cool. So in the future my focus is on building an awesome product first, winning prizes second.

During my time in Japan I was mainly focused on my project, so I didn't attend any events there. But after leaving Japan at the end of July, I returned to TruffleCon in Seattle, where I gave a talk like the one I did for Truffle University. It was great to be back at TruffleCon this year. It remains one of my favourite events in the crypto space as it has a big focus on practical topics.

TruffleCon 2018 was in downtown Portland, so it was very easy to grab a bite or a drink after the talks. There were also some organised social events around the conference, making it easy to socialise. This year there were fewer official social events, and the conference took place outside the city, so it was more difficult to go out afterwards. Not that it stopped us!

After our time in the US we briefly returned home to Amsterdam. But this didn't last long, as I was invited to come over to Townsville, Australia for the Bitcoin Cash City conference. What I liked about this event is that it had the same developer focus that I was used to with events like TruffleCon. So it was great to share this vibe with some of the awesome people in the BCH community.

We decided to stay in Asia a bit longer and in October I attended Devcon V in Osaka, the quintessential yearly Ethereum conference. I met some great people and I reconnected with many people I knew already.

I gave some (slightly work-in-progress) talks at side events and the Devcon community stage about the differences between smart contracts on Ethereum and Bitcoin Cash. It's quite difficult to articulate the most important differences, since Ethereum, Bitcoin, and Bitcoin Cash are fundamentally different beasts.

After travelling around for a bit longer, my final event of the year was the London Bitcoin Cash meetup. By that time I had gone through several more iterations of the same talk, and I presented on the differences between ETH, BTC and BCH in terms of smart contracts. The talk was well-received and I published its contents in my article Smart contracts on Ethereum, Bitcoin and Bitcoin Cash.

🛩 Travel

While many things happened in 2019, the biggest change was spending more time outside of The Netherlands than inside. This started with my project in Tokyo, and continued with all the events I wanted to attend in the second half of the year. But in between those events we also decided to travel around for fun.

We traveled around Japan (Tokyo, Kyoto, Kamakura), with some smaller trips to Korea, Taiwan and Thailand. After leaving Japan we traveled through some of the US (Hawaii and the West Coast). After getting back to The Netherlands for two weeks, we flew over to Australia, then to Bali.

From Bali we traveled on to Osaka for Devcon after which we revisited Korea and the US again (Chicago, Denver and NYC this time). From New York we flew over to London, and finally completing our second time around the world back to Amsterdam at the end of 2019.

📈 2020

2019 was full of change for me. It marked an end to my 5 years of university and I went from living in Amsterdam to traveling the world. In my previous year review I wrote that I would speak at more conferences, travel to more places and graduate. And I did.

With the current situation around COVID-19 it is good to be steady in the same location for a while, so I can't look ahead and make those predictions again. It will take some time for travel to resume and many events have been canceled, postponed or moved to the virtual space.

This could be a nice opportunity to take part in more virtual events, but I don't think they are a real replacement for actual personal contact. In any case I am looking forward to an exciting 2020 (but perhaps not too exciting!).

A few years back I created a few small video games using the Lua-based game development framework LÖVE (or love2d). Because they are so small, it doesn't make sense to distribute these games for desktop platforms. But they are great as browser games, so I used Tanner Rogalsky's love.js to convert the games to JavaScript.

The first game I published this way was my Minesweeper clone. This was years back, using LÖVE version 0.10.0. Back then the process was more complicated, but also more reliable. Now the love2d engine is at version 11.3 (they dropped the leading zero), and sadly love.js has not been able to keep up.

Despite this, it is still possible to build your LÖVE games using love.js, which I recently went through for my Tetris clone. But there are some things to look out for. So in this article we will go through the required steps, and add an extra section for troubleshooting common errors.

Before we start

Although you technically don't need to have LÖVE or Lua installed for the actual build process, I do recommend installing it when developing LÖVE games 😉! Besides that, make sure that you have Node.js installed so you can use NPM. Then use NPM to install the latest version of love.js.

npm install -g love.js

If you want to deploy your game using Docker, make sure to install it as well, but this is optional since you can also publish your game to the web without it.

Building a web version of the game

With love.js installed we can build our love game for the web. We can do this with either a game directory or a .love file. It is recommended to use a .love file as this makes sure that only the necessary files are included, keeping the bundle size smaller.

1. Make the game files love.js compatible

Not all current Lua and LÖVE functionality is available in love.js, but luckily most is. These bullet points discuss the most important limitations. This list has information from love.js, LoveWebBuilder, the LÖVE forums, and my own experiences.

• Love.js can only be used for smaller games. Although there is no limit, larger games have a higher chance of crashing or bugs.
• If the t.version in your conf.lua file is set to something other than 0.11.0, your game might fail to run. This can be fixed by commenting out t.version before building.
• The canvas size of your game cannot be set or reset from your game code, so make sure that you set the dimensions in your love.conf file with t.window.width and t.window.height.
• Threads are unavailable in the browser, this means that LÖVE threads and audio streams cannot be used. So make sure that you're not using love.thread and that all audio sources are set to type "static".
• FFI is not supported, so using FFI in your game files, or using any libraries that use it is not supported.
• Love.js does not work with system-installed libraries, like those installed with Luarocks. Instead, all libraries should be included as Lua files in your game directory.

2. Create a .love file

We can create a .love file by bundling all game files in a ZIP file and giving it a .love extension. Depending on your platform, this can be done in different ways. There is usually an option in your file explorer, but on Linux and macOS you can also use the zip command line utility.

zip -9 -r <game name>.love <game files>

You can put the whole directory in this ZIP file, but the idea is to only include the necessary game files. In case of packaging my Tetris clone, it looked like this.

zip -9 -r Tetris.love assets/ lib/ src/ main.lua conf.lua

3. Generate your game's JavaScript code

With the .love file generated and love.js installed, we can easily generate the corresponding JavaScript and HTML on the command line.

love.js <love file> <output dir> --title <title> --memory <max memory>

When running the command it is important to set the --memory flag to a high enough value as this cannot be changed after the build. Generally the default option of 16MB should be doable, but it can't hurt to go a bit higher. For my Tetris game I just opted for 64MB as a ceiling.

love.js Tetris.love ./dist --title "Tetris" --memory 67108864

This outputs the generated code in the ./dist directory, from where it can be copied over to a web server or tested locally. You do need to run a web server to run the game though, you cannot just open index.html and be done with it. But a simple Python web server should be fine.

python -m SimpleHTTPServer 3000

After running the web server you can access the game in a browser at localhost:3000.

4. Dockerise the build process

Now this next step is entirely optional. If you want you can just copy over your generated code to any web server to host it, but Docker is a great tool for simplifying deployments. By Dockerising you essentially automate the build process, which saves time if you need to repeat the process.

The way Docker works is we create a Dockerfile, which is a series of instructions that tells Docker what files it needs, and what it needs to do with these files to build and run our game.

Create a Dockerfile

We start by creating a file named Dockerfile in the root game directory, which will tell Docker how it should package our game into a Docker image, which can then be deployed in a Docker container.

Once we created the Dockerfile, we tell Docker to base our image on an existing public Dockerfile, called node:10. We add as build, which gives the Docker image the name build, so we can refer to this Docker image later on.

FROM node:10 as build

Copy the game files

Next we add a few lines to the Dockerfile to copy over all game files to the Docker image. This is similar to creating a .love file, but we put all game files in a folder named /app/src instead of a ZIP file.

After copying, we use the sed command to automatically comment out the conf.lua line containing t.version. This is necessary due to the caveat discussed in step 1.

WORKDIR /app/src
COPY assets ./assets/
COPY lib ./lib/
COPY src ./src/
COPY main.lua conf.lua ./
RUN sed -i "s/t.version/-- t.version/" conf.lua

Building the game with love.js

In the previous steps we told Docker what files it needs. Now we tell Docker what it needs to do with these files. In our case, it should install love.js and run the correct love.js command, like we did manually in step 3. This will take the game files found in /app/src and place the generated JavaScript game in /app/dist.

RUN npm install -g love.js
RUN love.js /app/src /app/dist --title "Tetris" --memory 67108864

Serving the generated files

After the build process is completed, we need to tell Docker how it should serve the generated files. For this we will create a new Docker image within the same Dockerfile, based on the nginx image. We then tell Docker to copy the files from the other image, that we named build earlier. The nginx image then automatically serves all files found under /usr/share/nginx/html.

FROM nginx:1.17.0-alpine
COPY --from=build /app/dist /usr/share/nginx/html

Building and running the Docker image

After following all previous steps, we end up with the following Dockerfile.

FROM node:10 as build

WORKDIR /app/src
COPY assets ./assets/
COPY lib ./lib/
COPY src ./src/
COPY main.lua conf.lua ./
RUN sed -i "s/t.version/-- t.version/" conf.lua

RUN npm install -g love.js
RUN love.js /app/src /app/dist --title "Tetris" --memory 67108864

FROM nginx:1.17.0-alpine
COPY --from=build /app/dist /usr/share/nginx/html

From here, we can build the Docker image with the docker command line tool.

docker build --tag game-image .

Then it can be run locally, after which it is accessible at localhost:3000.

docker run --publish 3000:80 --detach --name game game-image

After running, the container can be shut down and removed again.

docker stop game
docker rm game

Once you're happy with the result, you will likely want to host your Docker container somewhere simple, like Heroku or Google Cloud. Or if you're the DIY type, you can set up a server with DigitalOcean and use the self-hosted Dokku to deploy your game.

Troubleshooting

If you followed the steps outlined above, you should be able to run your game in the browser with or without Docker. However, it's possible that you still run into issues. So in this section we discuss some errors that I experienced myself, but if you run into something else, leave a comment below.

My game is showing Lua errors

The first step with Lua errors is making sure that these errors disappear when you're running your game locally with LÖVE. If they also occur that way, there is likely an unrelated bug in your code that needs to be fixed first.

If the Lua errors only occur in the browser, it is most likely that not all required files were included. So double check that you included all files in your .love file or Dockerfile. Note that these are likely to be different files than those in the example.

It is also important to reiterate that love.js does not work with system-installed libraries, so any libraries like middleclass or penlight need to be included as Lua files in your game folder.

Some errors that can indicate missing files are module 'xxx.yyy' not found, attempt to perform arithmetic on global 'XXX' (a nil value) or No code to run.

The page is showing a black rectangle

If the page is showing a black rectangle where the game should be, the most likely cause is also missing files.

My game is not showing on the screen

If your game is not showing after loading the page, you should check the JavaScript console for errors. In most browsers you can right click the page and select Inspect or Inspect element, then navigate to Console. This shows all JavaScript errors.

The console will always show some errors about threads or audio, because these features are not working reliably in the browser. These errors can be ignored, although they might be difficult to distinguish from more important errors.

> TypeError: Failed to execute 'decode' on 'TextDecoder'

This is a very non-descriptive error, but it generally happens if you forget to comment out the target version inside your conf.lua file. Make sure that you really comment it out or include the corresponding line in your Dockerfile.

The Dockerfile assumes that your config function signature is function love.conf(t). But it is possible that you gave t another name, like tbl or config. In that case you should adjust your Dockerfile accordingly.

My audio is not playing correctly

If your audio stops playing all of a sudden, you might have forgotten to set your audio sources are set to "static". When importing audio files with love.audio.newSource, make sure that the second parameter is set to "static" - see the example below. Note that the official LÖVE wiki recommends using "stream" instead of "static" for background music, but this advice should be disregarded when using love.js.

background_music = love.audio.newSource("assets/audio/background_music.mp3", "static")

Unfortunately audio can still be a bit inconsistent, even when using the "static" type. So for things like background music you might find that the looping doesn't work very well. But it usually works well enough.

Alternative option: LoveWebBuilder

The good thing about the methods described in this article is that it can be largely automated. Either by using Docker, or by adding the build process to a Makefile. This also means that the deployment of your game can be automated like with most other web development.

But maybe that is not important to you. Maybe you don't want to go through all these steps just to build your game for the browser. Or maybe you don't plan on repeating this deployment, so you don't value the automation.

In that case, there is another tool that is built on top of love.js, called LoveWebBuilder by Bernhard Schelling. It still uses love.js for the Lua-to-JavaScript conversion, but LoveWebBuilder is available as a simple to use web application. You just need to select a .love file from your computer and enter some information. The rest is all handled by LoveWebBuilder, making it very accessible for one-time deployments.

Conclusion

Love2d games can be converted to browser games with love.js as long as some of the prerequisites are met. This build process can be automated with Docker by creating a Dockerfile with all build steps. There are some common issues that you could run into, which can usually be solved with the steps outlined above. An alternative to love.js is LoveWebBuilder, which can be used if you prefer to use a simple web-based UI.

Let me know in the comments below if you've published any love2d games on the web so I can check them out. Also let me know whether you followed this guide, used LoveWebBuilder or used a different build process altogether! And don't forget to share this article with your gamedev friends on Facebook or Twitter!

Ethereum was the first platform to enable Turing-complete smart contracts back in 2015. It is still the most popular platform for smart contracts, even as other smart contract platforms have emerged, like EOS or Tezos. And although Ethereum was the first platform with Turing-complete smart contracts, it was already possible to create rudimentary contracts on Bitcoin using a language called Bitcoin Script. And Bitcoin Cash has recently been improving its smart contract capabilities. While not as advanced as Ethereum's, they allow for useful on-chain contracts with unique benefits.

This article focuses on the unique differences between smart contracts on these three platforms. Since the focus is on the smart contract and scripting functionality, we don't go into the platforms' fundamentals or blockchain in general. This article is also specifically about on-chain smart contracts. Several second layer smart contract solutions exist, such as RSK. These solutions are definitely worth discussing, but are better suited for an article of their own.

Ethereum: Stateful & Turing-complete

Ethereum is the biggest smart contract platform in the world, and with good reason. Smart contracts in Ethereum use the Ethereum Virtual Machine (EVM), which is a Turing-complete Virtual Machine. This means that the EVM is able to compute anything, given enough resources. This is conceptually similar to many other general-purpose platforms, such as the JVM, which is used in the execution of Java programs.

The EVM explained

A big difference between these general-purpose platforms and Ethereum's EVM is that Ethereum's smart contract code is executed by all Ethereum nodes to verify transaction validity. To compensate mining nodes for the execution of this code, all EVM opcodes have an associated gas cost, referenced in the image below.

Every transaction uses an amount of gas, depending on the opcodes used. Gas is paid for with Ethereum's native currency, Ether. To limit the amount of computation these nodes have to do per block, there is a limit on the amount of gas that can be used in a single block, called the block gas limit.

During the execution of smart contract functions, contracts can store and access the necessary data. This data can live in different locations depending on its use. First is the stack, which holds the values used in computations. Only the top 16 items on the stack can be easily accessed, so it's not suitable for longer term storage. The use of a stack for computation is shown below.

To complement the stack, the contract memory data location is used to store, retrieve and pass data within the current contract execution. The values can be retrieved from memory to be used on the stack for computation and the results can be stored back in memory. These values only persist during the current execution; at the end of the execution the memory and stack are wiped.

The final data location is contract storage, which is used to persist data across contract executions. Persistent variables, like token balances, are stored in contract storage. To achieve data persistence, the contract storage is stored on every Ethereum node. So memory is analogous to RAM, while storage is analogous to hard drive storage or a persistent database.

More information about the inner workings of the EVM can be found in this excellent article by MyCrypto.

Writing smart contracts

While all smart contracts use the EVM, most of them are not written by hand using EVM bytecode, like most JVM bytecode is not written by hand. Instead there are several high-level languages that can be used to write smart contracts in Ethereum. The most popular language for this is Solidity, but Vyper also sees some usage. An example of a very simple Solidity smart contract is included below.

pragma solidity ^0.5.0;

contract SimpleStorage {
  uint storedData;

  function set(uint x) public {
    storedData = x;
  }

  function get() public view returns (uint) {
    return storedData;
  }
}

Interacting with smart contracts

Smart contracts in Ethereum exist as bytecode on the Ethereum network. This means that Solidity code gets compiled to bytecode, which is then deployed to the network by sending a deployment transaction. This is a special kind of transaction without any recipient but with the bytecode as the transaction data.

These deployed contracts exist only as blobs of EVM bytecode on the network, which are nearly impossible to use on their own. To interface with them, an Application Binary Interface (ABI) needs to be provided, which includes a list of all public functions and their parameters. To grant more insight into these contracts, there are services like Etherscan that allow you to verify contract source code so users can inspect the code before using the contracts.

All smart contracts can be accessed directly by connecting to an Ethereum node and using its JSON-RPC interface. But many smart contracts are instead accessed through a frontend application that connects to a node and manages the ABI. This can be done with one of many different Ethereum SDKs like web3js or ethers.js, which call the JSON-RPC under the hood. This offers a better experience for contract users, as the most difficult parts are abstracted away.

Smart contracts can be interacted with in two different ways: through calls and through transactions. A call is a local invocation of a contract function, and it does not broadcast anything to the blockchain. Because of this, calls are read-only, can not make any changes to the contract state and do not incur any fees.

On the other hand, transactions are write operations that do get broadcasted to the network, are included on the blockchain and do incur a miner fee. To take ERC20 tokens as an example, token balances are retrieved with a call, while tokens are transferred with a transaction.

Interaction between smart contracts

These properties of Ethereum - a Turing-complete VM and persistent storage - allow you to create any kind of decentralised applications running on-chain. A great example of this is the DeFi ecosystem, with applications such as Maker, Uniswap and Compound, as well as the ERC20 and ERC721 token standards. These applications allow for complex functionality with an unlimited number of dynamic participants.

On top of that, smart contracts themselves can be participants in other smart contracts, allowing for strong integration and composition between these contracts. An example is a smart contract holding a token balance and lending them out on Compound or exchanging them with Uniswap. Another example is using rDai to automatically invest DAI and contribute the accrued interest to charity.

While smart contracts can interact with each other, every on-chain transaction needs to be originated from an external account. So contract-to-contract interactions still have to be triggered through an initial transaction by a user. After this initial trigger, contract-to-contract interactions are similar to direct interactions.

In other words, it's possible for contracts to call read-only functions of other smart contract or trigger write operations. Since only external accounts can trigger transactions, write operations between contracts are referred to as internal transactions or message calls to make the distinction with user-initiated transactions.

Bitcoin: Stateless & simple

All Bitcoin transactions, including regular transfers, are powered by a stack-based programming language called Bitcoin Script. And while the EVM has been designed for Turing-complete and integrated smart contracts, Bitcoin Script is intentionally more limited and works in a fundamentally different way.

Bitcoin Script explained

Like the EVM, Bitcoin Script uses a stack to hold values and perform computations on these values. But unlike the EVM, the stack is the only data location available in Bitcoin Script. This means that it's difficult to store multiple values to use later in the contract execution. But more importantly, this means that it is impossible to store and modify values that persist across contract executions.

This is the biggest difference between Ethereum's smart contracts and Bitcoin's. Ethereum's model is stateful, while Bitcoin is stateless. Ethereum can be considered analogous to the common imperative mutable-data programming paradigm, while Bitcoin is analogous to the functional immutable-data paradigm.

Bitcoin's model allows transactions to be verified independently and much more efficiently, which makes it easier to parallelise and shard transactions. But without any mutable data storage, it is more difficult to create the complex smart contracts that Ethereum allows. ERC20 contracts, for example, have to keep track of token balances and change them.

Besides these differences in state, there are other things limiting complexity in Bitcoin's smart contracts. Notably, Bitcoin Script lacks support for some arithmetic functions and any form of looping or recursion. Contracts also have an effective size limit of 520 bytes and can contain 201 opcodes at most.

Most smart contracts on Bitcoin fall in a few categories of simple contracts. Examples are multisig contracts that can be spent by multiple participants, or Hashed Timelock Contracts (HTLCs) that can be spent by revealing a secret or reclaimed after time has passed. And because these contracts are very simple, most of the value is gained from combining different contracts with additional off-chain application logic. That way simple contracts can be combined to create complex solutions such as the Lightning Network or Atomic Loans.

Bitcoin transactions explained

Bitcoin transactions are created using indivisable chunks of Bitcoin, called transaction outputs. When these outputs are available, they are called Unspent Transaction Outputs (UTXOs). UTXOs are locked using a locking script (or scriptPubKey) that specifies the conditions to spend the output. When attempting to spend a UTXO, an unlocking script (or scriptSig) is provided. These scripts are then executed together; the transaction is only valid if the scripts execute without errors and the resulting value is TRUE.

As with the EVM, all Bitcoin nodes execute these scripts to validate the transactions, but Bitcoin lacks the notion of a gas cost, so instead fees are paid to the miner per byte of transaction data. To limit the work that the nodes have to do, there are also limits in place on some of the more intensive script operations.

Interacting with smart contracts

Smart contracts in Bitcoin are written using the Pay-to-Script-Hash (P2SH) pattern. The locking script in the P2SH pattern contains a script hash, and requires an unlocking script that provides the full script (called the redeem script) as well as the unlocking script for this redeem script. The image below shows this pattern.

The Bitcoin node software validates these smart contract transactions in two phases. First, the redeem script is hashed and checked against the hash in the locking script. If they match, the unlocking script is used to unlock the redeem script as if the redeem script was the initial locking script.

Because only a hash of the bytecode is stored on-chain, the full bytecode has to be stored off-chain, and included in the unlocking script of any contract execution. Because of this, "deployments" of smart contracts are free, but later contract executions are more expensive. Conversely, initial deployments in Ethereum are relatively expensive, while later contract executions are cheaper.

These differences in deployment encourage different kinds of smart contracts. A good example is LocalCryptos, which supports non-custodial local trading for both Ethereum and Bitcoin. For Ethereum it uses a big contract that keeps track of all trades, while for Bitcoin it creates individual contracts for every trade.

Writing smart contracts

While Ethereum has multiple high-level languages that compile to EVM bytecode, there is less of a focus on this with Bitcoin. Although the systems that can be built with them are complex, Bitcoin contracts themselves are usually quite simple. So there is less of a need to abstract away the underlying system. And because of Bitcoin contracts' size limits and high costs per added bytes, it is important to keep contracts as small as possible.

While these kinds of high-level languages are less important in Bitcoin, they do exist. The most elaborate high-level language for Bitcoin is Ivy, which was created in 2017 by Dan Robinson. An example smart contract written in Ivy is included below. The contract can be used to send money that can be reclaimed by the sender if the recipient doesn't spend it timely.

contract TransferWithTimeout(
  sender: PublicKey,
  recipient: PublicKey,
  timeout: Time,
  val: Value
) {
  clause transfer(senderSig: Signature, recipientSig: Signature) {
    verify checkSig(sender, senderSig)
    verify checkSig(recipient, recipientSig)
    unlock val
  }
  clause timeout(senderSig: Signature) {
    verify checkSig(sender, senderSig)
    verify after(timeout)
    unlock val
  }
}

More recently several researchers at Blockstream released Miniscript, which is a language focused on analysis and composability of smart contracts, rather than abstracting away the underlying system. This seems to be the right path, given the fact that Bitcoin contracts tend to lack the complexity that needs more abstraction.

Bitcoin Cash: Combining features

On one hand there is Ethereum, which is able to create many powerful and useful smart contracts that live completely on-chain. At the same time it presents scaling issues due to its stateful nature. On the other hand, Bitcoin's stateless model for smart contracts allows for independent, simple verification of smart contract transactions. But its scripting system limits the usefulness of its contracts.

Bitcoin Cash and Bitcoin share the same history until they forked, so their underlying scripting systems are the same in functionality and Bitcoin Cash benefits from the same upsides. Since then, a part of the Bitcoin Cash community has recognised the demand for more useful smart contracts. Bitcoin Cash has enabled new functionality, making its smart contracts more useful, while keeping the essential properties that allow for Bitcoin's stateless verification.

Upgraded functionality

To understand the possibilities of smart contracts on Bitcoin Cash we need to look at its biannual network upgrades. These network upgrades are performed every year in May and November since the original hard fork in 2017. We specifically discuss the changes to the Bitcoin Script engine, although several other improvements have been made, such as Schnorr signatures.

Early on in Bitcoin, several opcodes were disabled due to issues that made them unsafe to use. Within the first year after the Bitcoin Cash fork, the developers of the Bitcoin-ABC node addressed these issues and reintroduced the opcodes with slightly amended functionality, shown in the image below. Most importantly, this update enables encoding and decoding of structured data within Bitcoin Script.

Half a year after this, another new opcode was released in the network upgrade of November 2018. The update included OP_CHECKDATASIG, which allows you to verify a signature for any message inside Bitcoin Script. If we combine all scripting updates that were introduced in 2018, these can be used to bring novel and useful smart contract functionality into Bitcoin Cash.

Writing smart contracts

The new functionality of Bitcoin Cash adds significant complexity to its smart contracts over the original Bitcoin Script. This makes it more important to have an ecosystem that provides higher levels of abstraction through high-level languages, SDKs and tooling.

The two big projects working on this right now are Spedn, which was created by the pseudonymous Tendo Pein, and CashScript, which was created by me and is syntactically inspired by Ethereum's Solidity. These tools make it easier to work with smart contracts in Bitcoin Cash, although they are still in development. We use snippets of CashScript code to illustrate functionality in the sections below.

Oracles

When the past updates to Bitcoin Script are combined, they allow you to bring external data into smart contracts on Bitcoin Cash through trusted oracles. Structured data can be encoded into a byte array, and signed by an oracle provider. Then the smart contract can verify the signature and decode the structured data.

An example of this can be inspected in the HODL Vault example contract below. This contract enforces HODLing until a certain BCH/USD price has been reached. The required BCH/USD price feed is published by an oracle provider and passed into the contract by the user. To increase decentralisation, a smart contract can be set up to use several data sources, rather than trusting a single centralised service.

pragma cashscript ^0.2.0;

contract HodlVault(pubkey ownerPk, pubkey oraclePk, int minBlock, int priceTarget) {
    function spend(sig ownerSig, datasig oracleSig, bytes oracleMessage) {
        // Decode message: { blockheight, price }
        int blockHeight = int(oracleMessage.split(4)[0]);
        int price = int(oracleMessage.split(4)[1]);

        // Check that message's blockHeight is after minBlock and not in the future
        require(blockHeight >= minBlock);
        require(tx.time >= blockHeight);

        // Check that current price is at least priceTarget
        require(price >= priceTarget);

        // Handle necessary signature checks
        require(checkDataSig(oracleSig, oracleMessage, oraclePk));
        require(checkSig(ownerSig, ownerPk));
    }
}

Covenants

The second big use case is a technique called covenants, which derives its name from a term used in property law to restrict an object's use. In the case of Bitcoin Cash, it restricts the use of money in a smart contract. So while smart contracts in Bitcoin can only authorise the general spending of money, Bitcoin Cash contracts are able to put constraints on the amount of money that can be spent or who the recipients can be, among other constraints.

When transferring Bitcoin, the sender has to provide a signature to authorise the transaction. To generate this signature, the sender signs a hash representation of the transaction. This hash is called the sighash, while the actual transaction data is contained in the sighash preimage.

By using OP_CHECKSIG and OP_CHECKDATASIG with the same signature, we can gain access to the sighash data. The data format can be inspected in the specification, and is included in the image below. An important field is scriptCode, which contains the bytecode of the smart contract itself. Another is hashOutputs that allows you to enforce the outputs of a transaction.

While it is good to know how covenants work on a technical level, CashScript has abstracted away most of the complexity associated with covenants. When writing smart contracts with CashScript these fields are readily available without going through the steps to verify and decode the sighash preimage manually.

The first smart contract to use covenants was Licho's Last Will, a smart contract that allows you to put a dead man's switch on your holdings. The contract defines three different functions. The first allows an inheritor to claim the funds after 180 days. The second allows the owner's cold key to spend the money in any way. The third allows the owner's hot key to refresh the 180 day duration by enforcing that the full contract balance is sent back to the contract.

A CashScript version of Last Will is included below, but the original version was written with Spedn and can be inspected here.

pragma cashscript ^0.3.0;

contract LastWill(bytes20 inheritor, bytes20 cold, bytes20 hot) {
    function inherit(pubkey pk, sig s) {
        require(tx.age >= 180 days);
        require(hash160(pk) == inheritor);
        require(checkSig(s, pk));
    }

    function cold(pubkey pk, sig s) {
        require(hash160(pk) == cold);
        require(checkSig(s, pk));
    }

    function refresh(pubkey pk, sig s) {
        require(hash160(pk) == hot);
        require(checkSig(s, pk));

        // Construct output
        int minerFee = 1000;
        bytes8 amount = bytes8(int(bytes(tx.value)) - minerFee);
        bytes32 output = new OutputP2SH(amount, hash160(tx.bytecode)

        // Check that output matches preimage
        require(hash256(output) == tx.hashOutputs);
    }
}

While this is one of the simpler examples of a covenant contract, it's possible to create much more interesting covenants. People have used covenants to create Mecenas, a recurring payment system, and Be.cash, a system for payer-offline payment cards. More recently we have even seen AnyHedge, a decentralised derivatives platform. So while Bitcoin Cash uses a different paradigm than Ethereum, it can support complex DeFi projects.

Covenants were first proposed in a paper titled Bitcoin Covenants, which required a new opcode, OP_CHECKOUTPUTVERIFY. Other proposals followed, such as BIP-119 or OP_CHECKSIGFROMSTACK. The latter is very similar to Bitcoin Cash's implementation of covenants. More practical information on covenants can be found in Tendo Pein's article on read.cash.

Simulated state

For the Last Will contract it can be valuable to change the inheritor when the contract is already in place. Since we can enforce sending to the current contract by looking at its bytecode, we can enforce sending to a slightly different contract by slightly changing this bytecode. Doing so, we create a function that sends the entire contract's balance to a contract with the exact same bytecode, but with a different inheritor.

We can only do this with constructor parameters of a known size (e.g. 20 bytes). The constructor parameters are always the first data of the contract's bytecode, which is how we are able to easily replace the old data with new data. The inheritor is the first constructor parameter and it has a size of 20 bytes, so we are able to apply this technique, as can be seen below.

    function changeInheritor(pubkey pk, sig s, bytes20 newInheritor) {
        require(hash160(pk) == hot);
        require(checkSig(s, pk));
        
        // Cut out old inheritor (PUSH1 0x14 <inheritor>) 
        // Insert new inheritor (PUSH1 0x14 <newInheritor>)
        bytes newContract = 0x4c14 + newInheritor + tx.bytecode.split(22)[1];

        // Construct output
        int minerFee = 1000;
        bytes8 amount = bytes8(int(bytes(tx.value)) - minerFee);
        bytes32 output = new OutputP2SH(amount, hash160(newContract));

        // Check that output matches preimage output
        require(hash256(output) == tx.hashOutputs);
    }

By using this technique, it's possible to change some variables in a contract while keeping the same rules of the contract. We refer to this as "simulating" state, since it offers some of the benefits of contract state, without some of the drawbacks of a stateful system. There is always a trade-off, so this method has different drawbacks.

The main issue is that we're not actually changing any variables in the original contract, since this is impossible due to Bitcoin Cash's statelessness. Instead, a new contract is created (with a new address) and the full balance can be transferred to this new contract. This causes UX problems due to the new address, but these can be mitigated by having a good application layer abstraction over these smart contracts.

Replacing these variables inside the bytecode can feel quite hacky, especially when trying to replace variables that are deeper inside the bytecode. This functionality should be abstracted away in high-level languages, so that the new bytecode is automatically generated by providing the new parameters. That kind of abstraction could look like this:

bytes32 output = new OutputP2SH(amount, hash160(new LastWill(newInheritor, cold, hot)));

Many abstractions come at the cost of larger contracts, which results in higher fees. Because transaction fees are generally quite low on Bitcoin Cash, this is not a deterrent. But Bitcoin Cash has the same size limits as Bitcoin, so these abstractions do make it more difficult to stay within the limits. This results in many developers having to hand-optimise the compiled bytecode.

Conclusions

Every cryptocurrency has trade-offs in its smart contract systems. Ethereum is the most used smart contract platform with the most extensive functionality. Bitcoin offers a more rudimentary version of smart contracts through its stateless scripting system. This stateless system is more efficient to validate, but offers less functionality. Bitcoin Cash builds on the same foundations as Bitcoin, but has added new functionality. This attempts to achieve a compromise between efficient validation and useful smart contracts. In the end, all are building towards similar goals.

Looking into the future

This article is written in Q4 of 2019, and reflects the current state of the platforms. Cryptocurrency is a fast-paced field, so the people involved with these platforms are always working on improvements that may change the outlook of the ecosystem.

Ethereum is working on a major Ethereum 2.0 release, with its phase 0 planned to go live in Q1 2020. Ethereum 2.0 aims to address the performance of Ethereum 1.x by moving to Proof-of-Stake, implementing sharding, and other improvements. The full roadmap for ETH2.0 is not set in stone yet, and it will likely take several years to roll out. But if this major update is able to to achieve its goals, this can present a strong case for Ethereum.

Smart contract research in Bitcoin is focused on further improving efficiency and privacy of smart contracts. This includes solutions like Taproot and scriptless scripts. At the same time Bitcoin Cash has enabled additional smart contract functionality and is focused on making these changes more accessible.

Disclaimer: I am the author of CashScript, one of the projects working on Bitcoin Cash smart contracts. I have also worked on and contributed to open source Ethereum projects, and currently maintain several Ethereum libraries. The goal of this article is not to advocate for any of the discussed platforms or technologies, but rather to provide a comprehensive comparison for anyone interested in working with smart contracts on Ethereum, Bitcoin and Bitcoin Cash.

One of the final Truffle updates of 2018 included the addition of Truffle plugins - the possibility to extend Truffle's functionality with new Truffle CLI commands. While it has been out for over half a year now, there has not been a lot of innovation in the form of new Truffle plugins. In fact, the list of awesome Truffle plugins currently counts just two plugins: truffle-plugin-verify and truffle-security.

Needless to say, it is time for more useful plugins to be developed. But the remaining questions are where do we start, and what even are the possibilities of these Truffle plugins? In this article we discuss how to create a Truffle plugin, and we discuss what these plugins can be used for.

Using Truffle plugins

Before being able to create Truffle plugins we need to understand how to use them and how to integrate one into an existing Truffle project. Luckily this process is very simple, as Truffle plugins are simply NPM packages that serve a very specific function - extending Truffle. After setting up a Truffle project, any plugin can be integrated into this project with a few simple steps.

First, all Truffle plugins can be installed into a project with NPM.

npm install truffle-plugin-verify

Next, these plugins need to be enabled by adding them to your truffle-config.js or truffle.js file under the plugins field.

module.exports = {
  /* ... rest of truffle-config */

  plugins: [
    'truffle-plugin-verify'
  ]
}

Any plugin should be usable with just these two steps, but some plugins might require additional steps, such as adding API keys or other additional parameters. So always be sure to check the README of a specific plugin.

module.exports = {
  /* ... rest of truffle-config */

  api_keys: {
    etherscan: 'MY_API_KEY'
  }
}

When a plugin is fully installed and enabled, it can be used from the Truffle CLI.

truffle run verify Casino --network rinkeby

How do Truffle plugins work?

All Truffle plugins are structured in the same way. They include a truffle-plugin.json file that maps one or more CLI commands to their corresponding JS files.

{
    "commands": {
        "hello": "hello.js"
    }
}

These JS files then have a single function as their default export. This function has a config object as a parameter that is used inside the function to implement the plugin's functionality.

module.exports = async (config) => {
  if (config.help) {
    console.log(`Usage: truffle run hello [name]`);
    done(null, [], []);    
    return;
  }

  let name = config._.length > 1 ? config._[1] : 'World!';
  console.log(`Hello, ${name}`);
}

The config object

The config object contains all the information you will ever need to start creating useful Truffle CLI plugins. The most important fields in this object are outlined below.

Config {
  // Information about the CLI
  truffle_directory: string, // Truffle executable location
  working_directory: string, // CWD
  _: string[], // Raw positional command line arguments

  // Any additional command line flags / arguments
  myString: string // --myString hello
  myint: number // --myInt 5

  // Information included in the truffle-config.js file
  networks: { rinkeby: object, ropsten: object },
  compilers: { solc: object, vyper: {} },
  plugins: string[],
  api_keys: { etherscan: string },
  /* ... any other fields defined in truffle-config.js */

  // Network config
  network: string, // --network rinkeby|ropsten|etc
  network_id: number // Current network id
  network_config: object // Current network config (from truffle-config.js)

  // Directory information
  contracts_directory: string, // ./contracts
  build_directory: string, // ./build
  contracts_build_directory: string, // ./build/contracts
  migrations_directory: string, // ./migrations
  migrations_file_extension_regexp: RegExp,
  test_directory: string, // ./test
  test_file_extension_regexp: RegExp,
}

The first thing we see in this config object is information about the CLI, including working directory and command line arguments. The object also includes any passed in command line flags, which gives the truffle plugin any functionality you would expect from other CLI-based tools.

The next thing that's included is all the information included in your truffle-config.js or truffle.js file. This includes things like network configuration and compiler settings, but also any other user-defined fields, such as the api_keys field that is used in truffle-plugin-verify. Besides the raw information, there's some additional Truffle magic included in the additional network information that is added based on the --network parameter passed into the CLI.

The final information in the config object is directory information. This is what really enables interesting functionality. It gives access to all migrations files and test files, which allows you to run these migrations or tests inside your plugin, or to inspect their source code. But what really opens doors are the contracts_directory and contracts_build_directory strings.

Retrieving contract information & using contracts

The contracts_directory field gives us access to all the contract source files. This can be used for things like code flattening, linting, compiling, static analysis, or any other kind of source code analysis. But for most use cases, this contracts_directory field is not even necessary, as the contracts_build_directory grants access to all Truffle artifacts produced by Truffle's compile process. These artifacts include the contract's source paths, pointing to contract's source files as well.

The Truffle artifacts grant access to much more though, as they include all the information about the contracts, including bytecode, ABI, source code, and even the contract's Abstract Syntax Tree (AST), allowing you to add some compiler-related operations to your Truffle plugins.

Furthermore, artifacts include the addresses of contract instances that have been deployed using Truffle's migrate functionality. This allows you to analyse these deployed instances by looking at their transaction history, emitted events, or gather information on these contracts through public APIs such as Etherscan's.

But it doesn't stop there, since the artifact also includes the contract's ABI, allowing the plugin to send transactions or call functions on this contract. And because the config object also includes the network configuration, the plugin can even use the contract on behalf of the user's account when they are using something like truffle-hdwallet-provider or truffle-privatekey-provider.

Creating a Truffle plugin

Now that we know how a Truffle plugin works technically, what information it gets, and what can be derived from this information, it is time to develop a useful Truffle plugin. In this article we walk through the creation of a simple, but not trivial Truffle plugin that can have production value.

truffle-plugin-store

The contract we will create is called truffle-plugin-store. It reads the the artifact file of a passed contract name, and sends this artifact to a storage server. We then query the storage server to get the number of stored artifacts for the specific contract name.

For the purpose of this tutorial, I have created a repository with boilerplate code that includes a simple storage server, a basic Truffle project, and the boilerplate code for a Truffle plugin. This repository can be found on GitHub. The repository's master branch contains only this boilerplate code, while the reference branch contains the fully implemented plugin.

Prerequisites

Before starting, you need to have Node.js, Truffle, and MongoDB installed locally.

1. Install Node.js.
2. Install Truffle

   npm install -g truffle
   

3. Install MongoDB

Setting up the repository

After cloning the repository, there are three components that need to be set up. The first is the artifact storage server, which needs to be running in a separate terminal window during the rest of the development process.

cd artifact-storage-server
npm install
npm start

The second component is truffle-plugin-store which contains the boilerplate code for a Truffle plugin. The third component is the simplestorage Truffle project that contains a very simple smart contract, and already has truffle-plugin-store included as a dependency. Its dependencies need to be installed, and the contracts need to be compiled.

cd simplestorage
npm install
truffle compile
truffle run store SimpleStorage

In case of the boilerplate code, this simply outputs 'hello' to the console.

Implementing truffle-plugin-store

The boilerplate code contains just the following code inside the store.js file.

module.exports = async (config) => {
  console.log('hello')
}

The first steps to actually implementing this plugin is figuring out the data we need to receive from the config object. In this case we want to retrieve the contract name, which is a positional argument. Then we want to retrieve this contract's artifact by reading the correct JSON file.

module.exports = async (config) => {
  const contractName = config._[1]
  const contractsBuildDir = config.contracts_build_directory
  const artifactPath = `${contractsBuildDir}/${contractName}.json`
  const artifact = require(artifactPath)
}

From here on we need to communicate with the artifact storage server. This server has two different endpoints: POST /artifacts which uploads a JSON artifact to the server and GET /artifacts/:contractName which retrieves the artifact count for a specified contract name. To communicate with the server we use the 'axios' library.

npm install axios

const axios = require('axios')

module.exports = async (config) => {
  const contractName = config._[1]
  const contractsBuildDir = config.contracts_build_directory
  const artifactPath = `${contractsBuildDir}/${contractName}.json`
  const artifact = require(artifactPath)
  
  const url = 'http://localhost:3000/artifacts'
  
  const { data } = await axios.post(url, { artifact })
  console.log(`Stored ${contractName} artifact with id ${data.insertedId}`)
  
  const { data: count } = await axios.get(`${url}/${contractName}`)
  console.log(`${count} ${contractName} artifacts stored in total`)
}

With these axios calls implemented the plugin now stores the compiled artifacts every time truffle run store SimpleStorage is run, as well as outputting the number of stored artifacts. This concludes the plugins functionality, but there are improvements that can be made to this code, such as an optional URL parameter --url that allows people to use any storage server. A proper plugin also contains extensive error handling, so that users understand when they misuse the plugins.

Conclusion

Truffle plugins can be used to add new functionality or commands to the Truffle CLI. The Truffle CLI provides the plugin with a config object with different parameters that can be used by these Truffle plugins. The truffle-plugin-store example shows the steps required to create a minimal but non-trivial plugin. With this you should be all set to start creating more complex plugins for your own use cases.

If you used this guide to create an awesome Truffle plugin of your own, add a PR to the awesome-truffle-plugins and let me know about it in the comments below. If you know 10x developers that want to get started with Truffle plugins, don't forget to share this with them on Facebook, Twitter, and LinkedIn.

Etherscan is the most popular explorer in the Ethereum space. And one of its big features is verifying the source code of smart contracts. Verification allows users of smart contracts to understand what a contract is doing before using it. This increases trust in these smart contracts, and benefits developers because users feel more comfortable using their smart contracts.

The main way smart contract developers can add verified source code on Etherscan is through the form on their website, but unfortunately this is a lot of manual work. You need to enter things like compiler version and constructor parameters, and you need to provide the contract source code in a flattened format that exactly matches the deployed code.

Some developers flatten their Truffle contracts using a command line tool and use the browser-based Remix IDE to deploy the flattened source code. Then they copy the same flattened code to the Etherscan verification form. This is a cumbersome process that should be automated.

That is why I created truffle-plugin-verify, a Truffle plugin that can be used to automatically verify your Truffle contracts through the Etherscan API. With this plugin you can verify your contracts with just a simple command:

truffle run verify ContractName

Prerequisites

For this guide we assume you already have a Truffle project with a deployment process set up. If you don't, you can refer to this Truffle tutorial that shows how to set up deployment of Truffle projects with Infura.

Note: You can also check out the source code for this guide on GitHub.

The contract

If you've read any of my previous articles, you know that I'm a fan of using a simple Casino contract as an example. With this contract a player can bet ETH on a number from 1 to 10. To make sure the contract does not go bankrupt, the player can only bet a small percentage of the contract's total balance.

The winning number is generated as a modulo operation on the current block number. This is fine for testing, but be aware that it would be easily abused in production.

In this guide, we will specifically split up the contract further so it's spread out over multiple files. This allows us to showcase the full functionality of the plugin.

contracts/Killable.sol

pragma solidity ^0.5.8;

contract Killable {
    address payable public owner;

    constructor() public {
        owner = msg.sender;
    }

    function kill() external {
        require(msg.sender == owner, "Only the owner can kill this contract");
        selfdestruct(owner);
    }
}

contracts/Casino.sol

pragma solidity ^0.5.8;

import "./Killable.sol";

contract Casino is Killable {
    event Play(address payable indexed player, uint256 betSize, uint8 betNumber, uint8 winningNumber);
    event Payout(address payable winner, uint256 payout);

    function fund() external payable {}

    function bet(uint8 number) external payable {
        require(msg.value <= getMaxBet(), "Bet amount can not exceed max bet size");
        require(msg.value > 0, "A bet should be placed");

        uint8 winningNumber = generateWinningNumber();
        emit Play(msg.sender, msg.value, number, winningNumber);

        if (number == winningNumber) {
            payout(msg.sender, msg.value * 10);
        }
    }

    function getMaxBet() public view returns (uint256) {
        return address(this).balance / 100;
    }

    function generateWinningNumber() internal view returns (uint8) {
        return uint8(block.number % 10 + 1); // Don't do this in production
    }

    function payout(address payable winner, uint256 amount) internal {
        assert(amount > 0);
        assert(amount <= address(this).balance);

        winner.transfer(amount);
        emit Payout(winner, amount);
    }
}

Verifying the contract

Now that we have our contract ready, we can show how simple it is to verify this contract with truffle-plugin-verify.

1. Install & enable truffle-plugin-verify

You can install the Truffle plugin using npm or yarn:

npm install -D truffle-plugin-verify
yarn add -D truffle-plugin-verify

When it is installed, you should add the following to your truffle-config.js file to enable the plugin with Truffle:

module.exports = {
  /* ... rest of truffle-config */

  plugins: [
    'truffle-plugin-verify'
  ]
}

2. Create an Etherscan API key and add it to Truffle

To create an Etherscan API key, you first need to create an account on the Etherscan website. After creating an account, you can add a new API key on your profile page, as seen in the image above. After creating a new key, it should be added to truffle-config.js file under api_keys:

module.exports = {
  /* ... rest of truffle-config */

  api_keys: {
    etherscan: 'MY_API_KEY'
  }
}

Of course you shouldn't commit this API key to your Git repository, so I suggest using dotenv to store the API key in a gitignored .env file and read it from there.

After following these steps, your full config file should look similar to this:

const HDWalletProvider = require('@truffle/hdwallet-provider');
require('dotenv').config();

module.exports = {
  networks: {
    rinkeby: {
      provider: function() {
        return new HDWalletProvider(
            `${process.env.MNEMONIC}`, 
            `https://rinkeby.infura.io/v3/${process.env.INFURA_ID}`
        )
      },
      network_id: 4
    }
  },
  plugins: [
    'truffle-plugin-verify'
  ],
  api_keys: {
    etherscan: process.env.ETHERSCAN_API_KEY
  }
};

Your specific config file might be different, but as long as you have a public network deployment set up, and your plugins and api_keys are set correctly, you should be good to go.

3. Deploy & verify the contract

Now that everything is set up to use truffle-plugin-verify, the only thing left is to actually deploy and verify the smart contract.

truffle migrate --network rinkeby

This should take some time, and will show information about the deployment, finally displaying something similar to this:

Summary
=======
> Total deployments:   2
> Final cost:          0.0146786 ETH

With the contract deployed we can use truffle-plugin-verify to run the Etherscan verification of our Casino contract:

truffle run verify Casino --network rinkeby

This will again take some time, and eventually return:

Pass - Verified: https://rinkeby.etherscan.io/address/0x2CEA970AE626C8114Ca12942e96c7c2E189C16b2#contracts

Conclusion

The "traditional" method of Etherscan verification can be cumbersome since there are several manual steps to go through every time you deploy a contract. As an alternative, truffle-plugin-verify offers a simple and automatic replacement for the manual verification process. It is easy to install, and can be used to verify any smart contract with a single command.

If you found this guide useful and wish to use truffle-plugin-verify inside your own projects, check it out on npm or GitHub. If you enjoyed using the plugin or if you have any suggestions, let me know in the comment section below. And don't forget to share this with your network on Facebook, Twitter and LinkedIn.

Some time ago, I stumbled upon Ahmad Awais' website after finding his recent VSCode course. Since 2015 Ahmad writes yearly review posts on his blog that outline the important achievements of the year. I enjoy these articles a great deal and they inspired me to start a similar practice on my own website.

In this article I will outline my experiences of 2018, and how they have changed me. Every year when I look back, I'm in awe of how much I can change in such a short time. This is the first year I'm writing this review down, which makes 2018 feel even more eventful than the previous years.

Writing

I've maintained a personal website for several years, but I only started this blog in Q4 of 2017. I started off my blog on a separate subdomain, but last October I had enough of it, so I moved everything to a single website on the kalis.me domain. This was a huge improvement, but it did cause a slight drop in SEO and organic traffic.

When I started, the focus of my blog was on my system setup, with Dotfiles: automating macOS system configuration as the cornerstone. In 2018 I shifted towards Ethereum and Blockchain, as you can see in my most-read article Checking events when testing Solidity smart contracts with Truffle. I only wrote three articles in 2018, a steep drop from four articles in Q4 of 2017 alone. But I did add two new pages with information on myself and my public speaking experience.

While the writing slowed down, the readership of my website is still growing, and I currently get between 300-400 unique page views a month. A big part of this is organic traffic, which is growing despite the drop I mentioned. In 2019 I want to further improve the organic traffic by researching more SEO techniques.

I'm currently writing three new articles that I plan to finish in the coming year:

• Automatically back up your Linux server to webDAV cloud storage with Borg Backup
• Testing Oraclize callback functions with Truffle
• Become a verified Brave Publisher and receive BAT Payments on your website

Tell me what articles you're looking forward to in the comments.

Blockchain

2018 has been all about blockchain for me. I started my blockchain journey when I decided to write my BSc thesis about data validation using blockchain. I built an audit trail that leveraged blockchain as a way to detect tampering with application data. I had to research the possibilities and limitations of blockchain, and I had to change the direction of the project several times. After these hiccups I ended up with a working prototype and a comprehensive thesis.

ConsenSys Academy

During my thesis I took some courses on edX and Coursera to better understand Ethereum and blockchain in general. Along the way I found the ConsenSys Academy, which started a new cohort just as I was finishing my thesis. I signed up, and got accepted for the summer program on a scholarship.

In this bootcamp I learned everything I needed to become a smart contract developer. I was able to apply these new skills in the final practical assignment of the bootcamp. The project I came up with was a decentralised autonomous casino that runs on the Ethereum blockchain.

This project features a roulette game using an oracle to generate a winning number. The casino house is funded by an unlimited number of investors who buy the Roscoin token. The value of this token is always derived from the balance of the casino. This means that all token holders share in the profits and losses of the casino contract.

In my Ethereum projects I employed full unit tests, but it proved difficult to test Ethereum-specific functionality such as events and reverting. I decided to fix my own problems by creating the truffle-assertions library, that solves these issues. It turns out I was not the only one with these problems, as the package currently gets around 3000 monthly downloads on NPM.

TruffleCon

In October I attended TruffleCon to connect with other people in the Ethereum space. I gave a presentation there, titled Using events to unit test smart contracts. It included several ways a smart contract developer can use events in their unit tests, and I explained how the truffle-assertions library helps with this.

At the conference I participated in a workshop about Drizzle and I upped my smart contract security game through several smart contract hacking challenges. I also attended talks by other professionals in the blockchain and open source space. Most importantly though, I met a lot of amazing people from all around the world and all kinds of different backgrounds.

TruffleCon was the first conference I ever attended, but it will not be the last. It felt inspiring to be among so many people and to be able to learn from them. At the same time it felt great to be able to share my own knowledge with these people in a meaningful way.

BUIDL Amsterdam

At TruffleCon I met David Truong, who happened to live in Amsterdam like me. He organises monthly Ethereum developer meetups called BUIDL Amsterdam. When I was back in Amsterdam I joined his meetups, and I loved the setup of these events. They are fully focused on developers, and include sessions on all different aspects of Ethereum development. I got more involved with the meetups and I gave a lightning presentation at BUIDL 4.

Bitcoin Cash

At this point I was confident in my Ethereum abilities, but I had almost no experience in the larger blockchain space. I was happy that an opportunity arose to get more involved with other blockchain projects as well. BTC.com organised the Amsterdam edition of the BCH DEVCON hackathon at the end of October. I decided to take part, and I ended up winning as well.

I came to the hackathon to learn more about the wider blockchain space, and to see what Bitcoin Cash development looks like. As it turns out, the BCH development ecosystem is way behind Ethereum's, but it does have a lot of potential. At the hackathon I met Adrian Barwicki, Bryan Lee-A-Leong and Nikolay Manolov, and together we set out to make our own contribution to this ecosystem of developer tools.

We created PandaCash, a local development blockchain inspired by Truffle Suite's Ganache. It allows BCH developers to quickly test their applications against this local blockchain. This eliminates the need to connect to a public test network during the initial development stage. You can spin up and shut down clean versions of this development blockchain, which makes it a great tool for running automated tests.

Adrian and I continued working on PandaCash after the hackathon to expand its functionality, while trying to get funding for continued development. Unfortunately this didn't turn out to be fruitful in the chaos of the Bitcoin Cash hard fork and the continued crypto downturn.

In the aftermath of the hard fork we did see a different opportunity in the fact that Ryan X. Charles left Bitcoin Cash in favour of Bitcoin SV. At the same time his content platform Yours.org started censoring users, and shut down. Adrian immediately started Honest.cash as an open source and censorship-free version of Yours.org and it picked up steam very fast. I joined Adrian later on when I had more free time, and we're currently working on improving the platform.

Open Source

I have always been a big fan of open source software, and a large part of my professional projects at Eurocommercial are already available on GitHub. Many personal projects (such as my ionic-soundboard and my minesweeper game) are also open source. Yet part of the open source philosophy to me is also contributing to the open source projects of other people.

So about a year ago I started contributing to other repositories on GitHub. Since then I have contributed to several big open source projects like Ghost and Hammerspoon.

My personal projects have also continued to gain traction. My dotfiles repository reached more than 75 stars, and my truffle-assertions library got 40 stars and is getting more than 3000 monthly downloads.

Both of these projects have also attracted outside contributors, so I'd like to give a huge shoutout to Zachary Nawar, Nick Barry and Zulhilmi Zainudin for contributing to truffle-assertions and to Emanuele Mazzotta for contributing to my dotfiles. I also want to thank everyone else that uses my open source projects and opens issues or comments on my repositories.

Academics

For most of my day to day life, I'm a student, so academics plays a big part in my life. This was a big year in that regard, as I graduated from my Bachelor program in Computer Science last July. After graduation, my thesis supervisor approached me about publishing my thesis work at a conference in December. Over the summer I condensed my 40-page thesis into a 6-page paper for publication, while trying to appeal to a broader audience as well.

Luckily, the hard work paid off, as the paper was accepted at the RBchain Workshop at CloudCom 2018 in Cyprus, where I presented it last December.

This year I also started my one-year Master's degree in Software Engineering at the University of Amsterdam. As it's only a one-year program, 2019 will be my final year as a student. After studying for five years this is something look forward to. In April I'm starting my graduation thesis and internship at Bitcoin.com, which lasts until August. So starting September 2019 my student days will be over.

2019

2018 was an exciting year for me. I graduated from my Bachelor's degree, started my Master's degree, learned Ethereum and blockchain development, won a hackathon, spoke at two conferences, published a paper, created a successful NPM package, and loads more.

I enjoyed 2018, and I'm looking forward to an even more exciting 2019. This year I will speak at more conferences and compete in more hackathons, I will finish my Master's degree, keep contributing to the open source community, and travel to more places.

Let me know about your own 2018 in the comments below and share your goals for 2019 with the world. Happy new year!

Require statements are a great tool to make sure that a Solidity function only gets executed when the right preconditions are met and that the results of functions meet the expectations. By adding require statements early in the functions, we can make sure that no gas gets unnecessarily wasted, and with Truffle v5 we can finally retrieve the revert reason as well. Since require statements and reverting are such a big part of Ethereum smart contracts, it is important that this functionality can easily be tested as well.

The truffle-assertions library includes the ability to assert that a transaction reverts as expected. It includes support for Truffle v5 revert reason strings, so your tests can include very specific assertions on why the transaction should revert. The library also includes a general function to test for different transaction failures, so if you want to test for out of gas exceptions, it has you covered.

Prerequisites

Before we start, we need Truffle, which can be installed using npm. Note that this guide is written for Truffle v5, but with a few changes it will work for Truffle v4 as well. To leverage the strength of reason strings, it is best to use Truffle v5 regardless.

npm install -g truffle@beta

We also need some sort of Ethereum test network, such as Ganache, which can be installed from their website, or with Homebrew if you are using macOS. Alternatively, it can be installed as a command line tool with npm. To use revert reason strings, only the command line version can be used.

brew cask install ganache
npm install -g ganache-cli

Next we create a project directory, and initialise a new Truffle project in it.

mkdir truffle-revert-tests
cd truffle-revert-tests
truffle init
npm init -y

Finally, the truffle.js configuration file should point to the correct test network. The default port is 7545 for Ganache, and 8545 for ganache-cli.

module.exports = {
  networks: {
    development: {
      host: "127.0.0.1",
      port: 8545,
      network_id: "*"
    }
  }
};

The contract

For this guide, we will use the same smart contract as in my previous article. The contract is a simple number betting contract that allows users to bet ether on a number from 1 to 10. Because we don't want this contract to go bankrupt, the player can only bet a small percentage of the contract's total balance. The winning number is generated as a modulo operation on the current block, which is fine for our testing purpose, but note that it is easily abused if it would be published.

contracts/Casino.sol

pragma solidity ^0.5.8;

contract Casino {
    address payable public owner;

    event Play(address payable indexed player, uint256 betSize, uint8 betNumber, uint8 winningNumber);
    event Payout(address payable winner, uint256 payout);

    constructor() public {
        owner = msg.sender;
    }

    function kill() external {
        require(msg.sender == owner, "Only the owner can kill this contract");
        selfdestruct(owner);
    }

    function fund() external payable {}

    function bet(uint8 number) external payable {
        require(msg.value <= getMaxBet(), "Bet amount can not exceed max bet size");
        require(msg.value > 0, "A bet should be placed");

        uint8 winningNumber = generateWinningNumber();
        emit Play(msg.sender, msg.value, number, winningNumber);

        if (number == winningNumber) {
            payout(msg.sender, msg.value * 10);
        }
    }

    function getMaxBet() public view returns (uint256) {
        return address(this).balance / 100;
    }

    function generateWinningNumber() internal view returns (uint8) {
        return uint8(block.number % 10 + 1); // Don't do this in production
    }

    function payout(address payable winner, uint256 amount) internal {
        assert(amount > 0);
        assert(amount <= address(this).balance);

        winner.transfer(amount);
        emit Payout(winner, amount);
    }
}

Testing this contract

In this guide we're interested in testing that the reverting functionality of this contract works as expected. When we look at the bet function of the smart contract, we see that it should only be possible to play when betting more than 0 ether, but less than the max bet, which is set to 1% of the total balance of the contract. To test this, we will verify that the contract reverts when we don't send any ether or when we send more than the max bet. We will also verify that the revert reason strings match the expectations.

Install the testing packages

First we will install the Chai assertions library (or a different assertions library) for generic assertions, and the truffle-assertions library for the smart contract assertions.

npm install --save-dev chai truffle-assertions

Write the tests

With the dependencies satisfied, they can be imported at the top of the test, and the correct functions can be used inside the tests. The contract will also be imported at this point.

const Casino = artifacts.require('Casino');
const assert = require("chai").assert;
const truffleAssert = require('truffle-assertions');

After this, we define a new contract scope, and add beforeEach and afterEach hooks to create a new contract for every test and to tear it down again.

contract('Casino', (accounts) => {
    let casino;
    const fundingAccount = accounts[0];
    const bettingAccount = accounts[1];
    const fundingSize = 100;

    // build up and tear down a new Casino contract before each test
    beforeEach(async () => {
        casino = await Casino.new({ from: fundingAccount });
        await casino.fund({ from: fundingAccount, value: fundingSize });
        assert.equal(await web3.eth.getBalance(casino.address), fundingSize);
    });

    afterEach(async () => {
        await casino.kill({ from: fundingAccount });
    });
}

With the plumbing of the test file out of the way, we can add tests for the reverting functions. In the first test we will send 2% of the contract's balance in ether, which should trigger the first require statement. In the second test we won't send any ether, which should trigger the second require statement. Note that the revert reason string can only be used from Truffle v5 onwards, and only with ganache-cli v6.1.3 onwards. If you're using older versions of these tools, the revert reason string should be omitted as a parameter to the truffleAssert.reverts() function.

it("should not be able to bet more than max bet", async () => {
    let betSize = fundingSize / 50;
    let betNumber = 1;

    await truffleAssert.reverts(
        casino.bet(betNumber, { from: bettingAccount, value: betSize }),
        "Bet amount can not exceed max bet size"
    );
});

it("should not be able to bet without sending ether", async () => {
    let betSize = 0;
    let betNumber = 1;

    await truffleAssert.reverts(
        casino.bet(betNumber, { from: bettingAccount, value: betSize }),
        "A bet should be placed"
    );
});

Putting these components together we end up with the full test file:

test/Casino.test.js

const Casino = artifacts.require('Casino');
const assert = require("chai").assert;
const truffleAssert = require('truffle-assertions');

contract('Casino', (accounts) => {
    let casino;
    const fundingAccount = accounts[0];
    const bettingAccount = accounts[1];
    const fundingSize = 100;

    // build up and tear down a new Casino contract before each test
    beforeEach(async () => {
        casino = await Casino.new({ from: fundingAccount });
        await casino.fund({ from: fundingAccount, value: fundingSize });
        assert.equal(await web3.eth.getBalance(casino.address), fundingSize);
    });

    afterEach(async () => {
        await casino.kill({ from: fundingAccount });
    });

    it("should not be able to bet more than max bet", async () => {
        let betSize = fundingSize / 50;
        let betNumber = 1;

        await truffleAssert.reverts(
            casino.bet(betNumber, { from: bettingAccount, value: betSize }),
            "Bet amount can not exceed max bet size"
        );
    });

    it("should not be able to bet without sending ether", async () => {
        let betSize = 0;
        let betNumber = 1;

        await truffleAssert.reverts(
            casino.bet(betNumber, { from: bettingAccount, value: betSize }),
            "A bet should be placed"
        );
    });
});

Running the tests

After writing the contract and the tests, we can verify that it is actually working by running all truffle tests.

truffle test

Which should result in an output similar to this:

Using network 'development'.

Compiling ./contracts/Casino.sol...


  Contract: Casino
    ✓ should not be able to bet more than max bet (47ms)
    ✓ should not be able to bet without sending ether (68ms)


  2 passing (768ms)

Conclusion

Reverting and require statements are an important part of designing secure smart contracts. The truffle-assertions library allows you to easily test this revert functionality by offering the truffleAssert.reverts() and truffleAssert.fails() functions. These functions make it possible to easily test for reverts or other failures (such as out of gas exceptions). From Truffle v5 onwards, it is also possible to assert the revert reason string to make these revert assertions even more specific.

In this guide, we only went through testing the reverting functionality of the smart contract. Combined with the event testing of my previous article, these tests cover a good part of the contract's functionality.

If you found this guide useful and wish to use truffle-assertions for your own use case, check it out on npm or github. If you used this library in testing your own Ethereum smart contracts, tell me about it in the comments below. And don't forget to share this with your smart contract developer friends on Facebook, Twitter and LinkedIn.

When testing Solidity smart contracts it is very helpful to check the events generated by those contracts. Especially asserting the arguments of the emitted events is a powerful tool. However, using web3 to watch for events inside tests proved to be impractical, and manually going through the returned transaction receipt can be tedious. This is why we will discuss using truffle-assertions in order to make straightforward assertions about smart contract events and their arguments.

I created the truffle-assertions library to assert that certain event types were emitted during a transaction, and especially to add complex conditions to the event arguments. In this guide we will explore how to use this library in order to check that certain events were emitted by a test contract and that their arguments fulfil the required conditions.

Prerequisites

Before we start, we need Truffle, which can be installed using npm. Note that this guide has been updated for Truffle v5, but with a few changes it will work for Truffle v4 as well.

npm install -g truffle

We also need some sort of Ethereum test network, such as Ganache, which can be installed from their website, or with Homebrew if you are using macOS. Alternatively, it can be installed as a command line tool with npm.

brew cask install ganache
npm install -g ganache-cli

Next we create a project directory, and initialise a new Truffle project in it.

mkdir truffle-event-tests
cd truffle-event-tests
truffle init
npm init -y

Finally, the truffle.js configuration file should point to the correct test network. The default port is 7545 for Ganache, and 8545 for ganache-cli.

module.exports = {
  networks: {
    development: {
      host: "127.0.0.1",
      port: 8545,
      network_id: "*"
    }
  }
};

The contract

For this guide we will use a simple number betting contract. With this contract a user can bet ether on a number from 1 to 10, getting paid back ten times their initial bet if they pick the correct number. We will also add the possibility to fund the contract. Finally, we will make sure that a player can only bet a small percentage of the contract's balance, so players can not bankrupt the contract by winning too often. The winning number is generated as a modulo operation on the current block, which is fine for our testing purpose, but note that it is easily abused if it would be published.

contracts/Casino.sol

pragma solidity ^0.5.8;

contract Casino {
    address payable public owner;

    event Play(address payable indexed player, uint256 betSize, uint8 betNumber, uint8 winningNumber);
    event Payout(address payable winner, uint256 payout);

    constructor() public {
        owner = msg.sender;
    }

    function kill() external {
        require(msg.sender == owner, "Only the owner can kill this contract");
        selfdestruct(owner);
    }

    function fund() external payable {}

    function bet(uint8 number) external payable {
        require(msg.value <= getMaxBet(), "Bet amount can not exceed max bet size");
        require(msg.value > 0, "A bet should be placed");

        uint8 winningNumber = generateWinningNumber();
        emit Play(msg.sender, msg.value, number, winningNumber);

        if (number == winningNumber) {
            payout(msg.sender, msg.value * 10);
        }
    }

    function getMaxBet() public view returns (uint256) {
        return address(this).balance / 100;
    }

    function generateWinningNumber() internal view returns (uint8) {
        return uint8(block.number % 10 + 1); // Don't do this in production
    }

    function payout(address payable winner, uint256 amount) internal {
        assert(amount > 0);
        assert(amount <= address(this).balance);

        winner.transfer(amount);
        emit Payout(winner, amount);
    }
}

Testing this contract

To test this contract's functionality, we will verify that Play events are emitted by the contract, and that its arguments match our expectations. We will also verify that a Payout event is only emitted when the player bets on the correct number, and that their payout is the correct amount.

Install the testing packages

First we will install the Chai assertions library (or a different assertions library) for generic assertions, and the truffle-assertions library for the event specific assertions.

npm install --save-dev chai truffle-assertions

Write the tests

With the dependencies satisfied, they can be imported at the top of the test, and the correct functions can be used inside the tests. The contract will also be imported at this point.

const Casino = artifacts.require('Casino');
const assert = require("chai").assert;
const truffleAssert = require('truffle-assertions');

After this, we define a new contract scope, and add beforeEach and afterEach hooks to create a new contract for every test and to tear it down again.

contract('Casino', (accounts) => {
    let casino;
    const fundingAccount = accounts[0];
    const bettingAccount = accounts[1];
    const fundingSize = 100;

    // build up and tear down a new Casino contract before each test
    beforeEach(async () => {
        casino = await Casino.new({ from: fundingAccount });
        await casino.fund({ from: fundingAccount, value: fundingSize });
        assert.equal(await web3.eth.getBalance(casino.address), fundingSize);
    });

    afterEach(async () => {
        await casino.kill({ from: fundingAccount });
    });
}

Since we understand how the algorithm determines the winning number, we know beforehand whether a bet will be winning or losing. So we can define tests for each case.

We will start by defining a test for the losing case. In this test we want to intentionally bet on the wrong number, after which we want to assert that a Play event has been emitted with the correct arguments, but that no Payout event has been emitted, because the player lost the bet. We do this by using the assertEventEmitted, and assertEventNotEmitted functions from the truffle-assertions library. Both take a transaction receipt to look in, the expected event type, and an optional filter function with additional conditions to the event's arguments.

it("should lose when bet on the wrong number", async () => {
    let betSize = 1;
    // we know what the winning number will be since we know the algorithm
    let betNumber = (await web3.eth.getBlock("latest")).number % 10 + 1;

    let tx = await casino.bet(betNumber, { from: bettingAccount, value: betSize });

    // player should be the same as the betting account, and the betted number should not equal the winning number
    truffleAssert.eventEmitted(tx, 'Play', (ev) => {
        return ev.player === bettingAccount && !ev.betNumber.eq(ev.winningNumber);
    });
    // there should be no payouts
    truffleAssert.eventNotEmitted(tx, 'Payout');
    // check the contract's balance
    assert.equal(await web3.eth.getBalance(casino.address), fundingSize + betSize);
});

Finally, we add a test for the winning case, where we want to assert that both a Play and a Payout have been emitted with the correct arguments.

it("should win when bet on the right number", async () => {
    let betSize = 1;
    // we know what the winning number will be since we know the algorithm
    let betNumber = ((await web3.eth.getBlock("latest")).number + 1) % 10 + 1;

    let tx = await casino.bet(betNumber, { from: bettingAccount, value: betSize });

    // player should be the same as the betting account, and the betted number should equal the winning number
    truffleAssert.eventEmitted(tx, 'Play', (ev) => {
        return ev.player === bettingAccount && ev.betNumber.eq(ev.winningNumber);
    });
    // player should be the same as the betting account, and the payout should be 10 times the bet size
    truffleAssert.eventEmitted(tx, 'Payout', (ev) => {
        return ev.winner === bettingAccount && ev.payout.toNumber() === 10 * betSize;
    });
    // check the contract's balance
    assert.equal(await web3.eth.getBalance(casino.address), fundingSize + betSize - betSize * 10);
});

When we put everything together we end up with the following smart contract test:

test/Casino.test.js

const Casino = artifacts.require('Casino');
const assert = require("chai").assert;
const truffleAssert = require('truffle-assertions');

contract('Casino', (accounts) => {
    let casino;
    const fundingAccount = accounts[0];
    const bettingAccount = accounts[1];
    const fundingSize = 100;

    // build up and tear down a new Casino contract before each test
    beforeEach(async () => {
        casino = await Casino.new({ from: fundingAccount });
        await casino.fund({ from: fundingAccount, value: fundingSize });
        assert.equal(await web3.eth.getBalance(casino.address), fundingSize);
    });

    afterEach(async () => {
        await casino.kill({ from: fundingAccount });
    });

    it("should lose when bet on the wrong number", async () => {
        let betSize = 1;
        // we know what the winning number will be since we know the algorithm
        let betNumber = (await web3.eth.getBlock("latest")).number % 10 + 1;

        let tx = await casino.bet(betNumber, { from: bettingAccount, value: betSize });

        // player should be the same as the betting account, and the betted number should not equal the winning number
        truffleAssert.eventEmitted(tx, 'Play', (ev) => {
            return ev.player === bettingAccount && !ev.betNumber.eq(ev.winningNumber);
        });
        // there should be no payouts
        truffleAssert.eventNotEmitted(tx, 'Payout');
        // check the contract's balance
        assert.equal(await web3.eth.getBalance(casino.address), fundingSize + betSize);
    });

    it("should win when bet on the right number", async () => {
        let betSize = 1;
        // we know what the winning number will be since we know the algorithm
        let betNumber = ((await web3.eth.getBlock("latest")).number + 1) % 10 + 1;

        let tx = await casino.bet(betNumber, { from: bettingAccount, value: betSize });

        // player should be the same as the betting account, and the betted number should equal the winning number
        truffleAssert.eventEmitted(tx, 'Play', (ev) => {
            return ev.player === bettingAccount && ev.betNumber.eq(ev.winningNumber);
        });
        // player should be the same as the betting account, and the payout should be 10 times the bet size
        truffleAssert.eventEmitted(tx, 'Payout', (ev) => {
            return ev.winner === bettingAccount && ev.payout.toNumber() === 10 * betSize;
        });
        // check the contract's balance
        assert.equal(await web3.eth.getBalance(casino.address), fundingSize + betSize - betSize * 10);
    });
});

Running the tests

After writing the contract and the tests, we can verify that it is actually working by running all truffle tests. Make sure that a Ganache or ganache-cli instance is running in the background.

truffle test

Which should result in an output similar to this:

Using network 'development'.

Compiling ./contracts/Casino.sol...


  Contract: Casino
    ✓ should lose when bet on the wrong number (372ms)
    ✓ should win when bet on the right number (490ms)


  2 passing (1s)

Conclusion

Events are already powerful tools within the smart contract development tool chain, and the truffle-assertions library allows you to use these events to test your smart contracts in a very straightforward way. The library offers a way to add any conditions for the event arguments to these assertions using a filter function, making it easy to look for very specific events.

This guide only discussed checking emitted events as a way to test smart contract functionality. Another strong method is asserting revert functionality of the smart contract, as explained in my other article. Combined, the tests from these two articles cover most of the contract's functionality.

If you found this guide useful and wish to use truffle-assertions for your own use case, check it out on npm or github. If you used this library in testing your own Ethereum smart contracts or if you just feel like sharing, tell me about your Dapps in the comments below. And don't forget to share this with your smart contract developer friends on Facebook, Twitter and LinkedIn.