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:

• Uniswap prompts you to grant their contract permission to transfer DAI tokens on your behalf.

• You sign and send the transaction and await the transaction confirmation.

• Uniswap prompts you to call a function that executes the swap.

• You sign and send the transaction and await the transaction confirmation.

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:

• Uniswap prompts you to grant their contract permission to transfer DAI tokens on your behalf using a signature.

• You sign.

• Uniswap prompts you to call a function that executes the swap with your signature.

• You sign and send the transaction and await the transaction confirmation.

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

The super token is a token as defined in the Superfluid protocol specification. Super tokens build on prior token standards that allow a smart contract to react to a token being transferred to or from it using a callback. By default, if a contract is not designed to receive the token, it will revert so you don’t rug yourself.

wait but mr, wats a callback?

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

Callback Diagram

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 user requests to send the super token to the app.

• The super token handles the accounting by decreasing the user’s balance and increasing the app’s balance.

• The super token triggers a callback to tell the app that it has received tokens.

• The app receiving the tokens reacts to the message that it has received tokens.

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.

• Uniswap prompts you to send DAI.

• You sign and send the transaction and await the transaction confirmation.

• You wonder why more people don’t use 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.

Well, reactive token transfers have a less-than-ideal history. Uniswap version 1 had a reentrancy bug that had to do with ERC777 callbacks that allowed attackers to drain token pools. This has since been patched in V2 and V3, but still exists as a lesson in reentrancy attacks.

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.

Ricochet, a dollar cost averaging super app, reacts to stream creation by issuing an entitlement to the next swap that happens (usually every 15 minutes or so).

The Continuous Auction example super app reacts to stream creation by transferring an NFT to the streamer with the highest flow rate.

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! 🤘

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:

• Uniswap prompts you to grant their contract permission to transfer DAI tokens on your behalf.

• You sign and send the transaction and await the transaction confirmation.

• Uniswap prompts you to call a function that executes the swap.

• You sign and send the transaction and await the transaction confirmation.

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:

• Uniswap prompts you to grant their contract permission to transfer DAI tokens on your behalf using a signature.

• You sign.

• Uniswap prompts you to call a function that executes the swap with your signature.

• You sign and send the transaction and await the transaction confirmation.

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

The super token is a token as defined in the Superfluid protocol specification. Super tokens build on prior token standards that allow a smart contract to react to a token being transferred to or from it using a callback. By default, if a contract is not designed to receive the token, it will revert so you don’t rug yourself.

wait but mr, wats a callback?

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

Callback Diagram

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 user requests to send the super token to the app.

• The super token handles the accounting by decreasing the user’s balance and increasing the app’s balance.

• The super token triggers a callback to tell the app that it has received tokens.

• The app receiving the tokens reacts to the message that it has received tokens.

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.

• Uniswap prompts you to send DAI.

• You sign and send the transaction and await the transaction confirmation.

• You wonder why more people don’t use 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.

Well, reactive token transfers have a less-than-ideal history. Uniswap version 1 had a reentrancy bug that had to do with ERC777 callbacks that allowed attackers to drain token pools. This has since been patched in V2 and V3, but still exists as a lesson in reentrancy attacks.

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.

Ricochet, a dollar cost averaging super app, reacts to stream creation by issuing an entitlement to the next swap that happens (usually every 15 minutes or so).

The Continuous Auction example super app reacts to stream creation by transferring an NFT to the streamer with the highest flow rate.

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! 🤘