Reactive Smart Contracts

Reactive smart contracts are smart contracts that can react to certain events using a type of function called a callback. In this article we will explore why smart contract reactivity is powerful and how it differs from common patterns used in the Ethereum Virtual Machine. This will be high level and assumes minimal knowledge of smart contracts or code.

The standard for having a smart contract interact with a user’s tokens is to have the user grant permission to the smart contract to transfer the tokens on their behalf, then have the user call a function on said smart contract.

An example of this would be Uniswap. Say, for example, you wanted to exchange DAI tokens for Wrapped Bitcoin tokens, the process would happen something like this:

The reason you have to grant it permission is when you ‘swap’, Uniswap transfers your DAI on your behalf, computes how much Wrapped Bitcoin you should receive, then transfers that amount out to you.

The most notable improvement to this that I’ve seen is the integration of an off-chain signature. The idea here is that you can sign for the ‘approve’ step without sending a separate transaction. So the process might look something like this:

Cool. So you’re running one transaction, but the user experience improvement is marginal at best.

Good question, hypothetical human! A callback in the context of smart contracts is a function to be called when an event occurs.

The above diagram visualizes the flow of information in a token transfer with a callback. To the end user, this is all just one transaction, but under the hood, a few things happen.

The receiver app can be programmed to execute any action when it receives tokens. In an auction, this would be the logic to set the new highest bidder. In a Uniswap pool, it would handle the swapping of tokens.

In a hypothetical Uniswap with ERC777 integration, the process of swapping from DAI to Wrapped Bitcoin might look something like this.

It’s that simple. Super tokens can’t be sent to smart contracts not designed to receive them and contracts that are designed to receive them will react to the transfer appropriately. In this case the smart contract would execute the swap and send the Wrapped Bitcoin to you.

As a smart contract developer, you have to take into consideration reentrancy attacks on transfers, that is, an attacker might send tokens with the intention of triggering callbacks maliciously. This should not be a deal breaker for you (seriously, do it for the users), this is just something you need to consider.

In the Superfluid protocol specification, transfers are not the only thing that can trigger reactive logic. Creating, updating, and deleting agreements can also trigger callbacks!

When a user creates a stream to a super app (smart contract that implements Superfluid agreement callbacks), it can react to the creation of that stream and execute some powerful functionality.

For more information on super apps, reactivity, and more, see the following resources. Also, feel free to reach out to me on Twitter or the Superfluid Discord any time!

Good hacking! 🤘

Related posts:

This article introduces representative labeling as a semi-supervised method to efficiently annotate unstructured text data for NLP and classification.

Waking up this morning and I came across a post from a friend of mine with the word “Fearless”. My friend shared a repost he had from a few years ago. And in this post, he shared this morning was the…

After I was broken up with–I felt defeated, lost, alone, unworthy and less than. It felt like my identity had been taken away from me and the world that I was comfortable in was tossed around like a…