Stream Scheduling With Superfluid & Gelato

Learn how to automate Start/Stop Superfluid streams in Super Apps. 🚀 One of the most extraordinary things about web3 is that we are still at an early stage and as we speak, the web3 ecosystem is growing with new protocols, toolings, etc., and regardless of our level of expertise, we can contribute to helping others as we are learning. This blog aims to help devs to use the gelato network with smart contracts and specifically for using Gelato automation with Superfluid Super Apps. among other features allows users to stream money/tokens to users/contracts with only one transaction and minimal capital lockup. The caveat is that you have to remember to stop the stream, if not the stream will continue endlessly. Please visit Superfluid website for further info Superfluid Protocol https://www.superfluid.finance/home allows you to execute tasks at a future point in time (for ex-web2 would be similar to a kind of scheduler). The main use case is for repeated tasks. For Superfluid streams we will only need one execution (start or stop) therefore we will have to deploy the task and at the same time the “cancel Task”. Please visit Gelato website for further info Gelato Network https://www.gelato.network/ This project showcases general-purpose examples of automating smart contracts with gelato as well as the application for superfluid streams presenting a very simple 3+3 Step guide to create programmable cash flows In order to do that we have deployed a showcase dapp at . we will interact with two main verified and deployed on mumbai contracts : https://gelato-superapp.web.app Party App Contract ( ) view on scan Gelato Super App Contract ( ) view on scan The code can be found in this repository https://youtu.be/yjmJZ6LuPig 3+3 Steps Guide to Gelatofy a Smart Contract Here you will find 3 + 3 easiest steps to add the gelato infrastructure and very easily automate your smart contract tasks: Wire Gelato infrastructure Gelato Funding Strategy Gelato Business Logic 3.1) Task Creation 3.2) Checker Condition 3.3) Executable Function Step 1: Wire Gelato infrastructure In order to interact with the gelato network, we will need to interact with the Gelato contracts (addresses can be found ). We will interact with three contracts: here The main contract for creating, canceling, getting transaction Fees, transfer fees, etc. We will inherit the contract , we will pass in the constructor the gelato ops and gelato treasury addresses and !. Ops Contract: OpsReady.sol we are good to go import {OpsReady} from "./gelato/OpsReady.sol"; import {IOps} from "./gelato/IOps.sol"; import {ITaskTreasury} from "./gelato/ITaskTreasury.sol"; contract PartyApp is OpsReady, Ownable { constructor(address payable _ops, address payable _treasury) OpsReady(_ops, payable(_treasury)){ } : We will require to interact with the gelato treasury contract for fund/withdrawal depending on our funding strategy (see step 2) Gelato Treasury Contract : We will interact with this contract in our tests… more on Bonus Track #2 Gelato Network The OpsReady.sol contract, as well as the interfaces, can be found in within the repository. You can just copy them and it works! gelato-files Step 2: Gelato Funding Strategy Gelato executes transactions at a future point in time, therefore we need to choose a way of funding the transactions that Gelato is going to execute on our behalf.There are two alternatives to do that: as long as you have a positive balance in the treasury contract, the future transactions will be executed. If we choose this alternative we need to interact with the Gelato Treasury Contract funding it. 1) Fund the Gelato Treasury Contract: function fundGelato(uint256 amount) public payable { require(msg.value == amount, "NO_FUNDING"); ITaskTreasury(treasury).depositFunds{value: amount}(address(this),ETH,amount); } function withdrawGelato() public onlyOwner { uint256 maxAmount = ITaskTreasury(treasury).userTokenBalance(address(this),ETH); ITaskTreasury(treasury).withdrawFunds(payable(msg.sender), ETH, maxAmount); } Our smart contract will transfer in every future transaction the amount requested to pay the fees. In this case, we won’t need to interact with the Gelato Treasury Contract but . 2) Fund every transaction: we must maintain a positive balance in our contract Step 3: Gelato Business Logic There are three main parts/steps that we have to define within the business logic: We will have to define a task to tell Gelato what we want to be executed. 3.1) Create the Task: function createTask() public { require(taskIdByUser[msg.sender] == bytes32(0), "TASK_STILL_ACTIVE"); bytes32 taskId = IOps(ops).createTask( address(this), /// Contract executing the task this.startParty.selector, /// Executable function's selector address(this), /// Resolver contract, in our case will be the same abi.encodeWithSelector(this.checkerStartParty.selector) /// Checker Condition ); taskIdByUser[msg.sender] = taskId; } In order to execute a future transaction, we will have to provide Gelato with the condition to check whether Gelato can execute or not 3.2) Checker Condition: function checkerStartParty() external view returns (bool canExec, bytes memory execPayload) { canExec = headachePresent == false; execPayload = abi.encodeWithSelector(this.startParty.selector); } Function that will be executed when conditions and/or time are met. 3.3) Executable Function: function startParty() external onlyOps { require(headachePresent == false, "NOT_READY"); lastPartyStart = block.timestamp; headachePresent = true; } https://gist.github.com/donoso-eth/0678b0613db36c6c332063c9f39cddfd Party App demo! Our First Gelato App is going to be very simple. It checks whether our gelato party has started or not. The party will always start if we don’t have a “headache” from the previous party. We can set manually when our “headache” is over and then the Gelato network will be able to execute the start party, setting a new start party timestamp and setting our “headache to true” Our screen is divided into two parts depending on our funding strategy. This contract allows three uses cases: Create a simple task funded with treasury: Details can be seen above Once the task is created we can go to the and we will see our task waiting for execution gelato ops website And after successful execution, the ops dashboard will show us something like this. Create a simple task funded with treasury and cancel after the first execution (we are going to use this pattern later on with our Superfluid streams). https://gist.github.com/donoso-eth/517e2dca691980de506229cbe27eee62 Create a simple task paying each transaction (not treasury funding) https://gist.github.com/donoso-eth/340ca96b53005dd457defab0991a735c Gelato Super App Demo Our Gelato super App will help us make superfluid streams programmable by automating the stop or the start of a stream. We will implement the gelato Infrastructure (Step 1) like in the party app and we choose Treasury funding as a Funding Strategy (Step 2) We will demo stopping a stream after some predefined minutes. Our Business Logic will look like this: https://gist.github.com/donoso-eth/e4fc0145ed75ed84309da1a467175931 Now if you have funded the treasury, have started a stream and the gelato has already been executed stopping the stream you have unlocked your Bonus!! Bonus Track #1: Go to Sleep and the Stream will Start. So far we have achieved to stop a stream automatically, but following the same logic, I may want to start streaming to a new employee exactly at 00:00 AM on the first day of work and I don’t want to stay awake every day because hopefully, we are going to hire a lot of employees! .. then (CFA Access Control List) to the rescue, with a simple call to the CFA constant agreement either from the SDK or directly to the contract on your behalf when a certain time is elapsed and a “Gelato Task” is executed. CFA ACL you may want to allow our Super App to start a stream In this use case, we are concatenating two tasks, when the first one is executed, the stream will be started, the task canceled, and another task to stop the stream will be created. https://gist.github.com/donoso-eth/5491f5f94409f9648fa196c3ed24ca3d Bonus Track#2: Master Hardhat Fork and Sky Rocket your Development Speed One of the pleasant experiences in blockchain development is the ability to one-click creation of….. As our dapps grow in complexity we will require to interact with existing on-chain contracts and we will have to mock/deploy protocols. In some cases that . The best alternative to overcome this issue is to work with a fork, with a very simple configuration within our (thks and for pointing out the right direction). if we want to remain local can be cumbersome and we will spend precious development time hardhat.config.ts Sam Flamini Hilmar X https://gist.github.com/donoso-eth/1dbfc57d3d40679e324048e1d7c01ab4 and then with the we will be able to create a “virtual” copy of the blockchain we are targeting. The blocks we create from now on will be stored locally and for the older ones we will query the “real” blockchain with our RPC provider (above we are using alchemy) npx hardhat node --network "hardhat" In our example, we are working with mumbai, the Superfluid contracts (Host, ConstanFlowAgreeent, Supertoken…), as well as the Gelato contracts (Network, OPS, and Treasury), exist with the state they had at the block number of the fork allowing us to interact with them as we would interact with the “real” blockchain. Now, you have your local “mumbai” with the additional helper methods to truly master the chain: https://gist.github.com/donoso-eth/148d031bbc57e6a3b6708367a52b0069 In our Dapp we are working with Gelato contracts. The “Executors” will take care to automate our tasks, but in our local “virtual” chain there are no executors… who will execute our tasks?. And the answer to that is very simple, . We can do that because we master our local blockchain, and we choose to be the executor. Hardhat provides us with the fantastic method and we will use it to become locally “the executor”. we are going to execute the task ourselves we can be whoever we want to be hardhat_impersonateAcount Here we can see the details of the implementation for executing gelato tasks impersonating the Gelato NetWork contract https://gist.github.com/donoso-eth/88b3e43f5957cf1e6cdbcd326067fee0 We will need to build the params to be able to execute the task, if we look in Ops interface we see that we need the following params /// @notice Execution API called by Gelato /// @param _txFee Fee paid to Gelato for execution, deducted on the TaskTreasury /// @param _feeToken Token used to pay for the execution. ETH = 0xeeeeee... /// @param _taskCreator On which contract should Gelato check when to execute the tx /// @param _useTaskTreasuryFunds If msg.sender's balance on TaskTreasury should pay for the tx /// @param _revertOnFailure To revert or not if call to execAddress fails /// @param _execAddress On which contract should Gelato execute the tx /// @param _execData Data used to execute the tx, queried from the Resolver by Gelato function exec( uint256 _txFee, address _feeToken, address _taskCreator, bool _useTaskTreasuryFunds, bool _revertOnFailure, bytes32 _resolverHash, address _execAddress, bytes calldata _execData ) external; Using one of our examples in the party app we will have: https://gist.github.com/donoso-eth/bacd13ccb9718d70f618eca6c82587f7 The implementation in our dapp tests can be seen in the . We use this technique in our contract tests. code Conclusion As we have seen, it is relatively simple to wire the gelato network into our smart contracts and unlock the full potential of automation. Specifically for Superfluid streams gelato can allow Super Apps to do stream-scheduling. Hope this article can help other devs to quickly get up and running with gelato and apply it to Superfluid streams. You can connect with me on Twitter @donoso_eth Also published . here