SuperAppBaseFlow

Making building Super Apps easier than ever

You may see the name "SuperAppBaseCFA" instead of SuperAppBaseFlow around our super-examples repo. We are in the process or renaming; eventually all mentions of SuperAppBaseCFA will be replaced with SuperAppBaseFlow.

What is the SuperAppBaseFlow

The SuperAppBaseFlow is an inheritable base contract that simplifies writing callbacks and abstracts away the redundancies of writing Super Apps. It can be used in lieu of the SuperAppBase.

SuperAppBaseFlow Code

Example Usage - Growing NFT Example Using SuperAppBaseFlow

SuperAppBaseFlow Simplifies Callbacks

The original SuperAppBase callback function headers are elaborate with unobvious parameter meanings. The SuperAppBaseFlow consolidates all callback development into 3 virtual functions (onFlowCreated, onFlowUpdated, onFlowDeleted) with much more readable parameters, making development easier for you.

Using the SuperAppBaseFlow

Import and Inherit

// Example Code
...
import { SuperAppBaseCFA } from "@superfluid-finance/ethereum-contracts/contracts/apps/SuperAppBaseFlow.sol";

contract SomeSuperAppContract is SuperAppBaseCFA {
...

Constructor

constructor(
    ISuperfluid host_,
    bool activateOnCreated,
    bool activateOnUpdated,
    bool activateOnDeleted
)

host_ - The address of the Superfluid Host for the network of choice. Find addresses here.

activateOnCreated - True if the Super App will implement onFlowCreated to react to the creation of streams to it. False otherwise.

activateOnUpdated - True if the Super App will implement onFlowUpdated to react to the updating of streams being sent to it. False otherwise.

activateOnDeleted - True if the Super App will implement onFlowDeleted to react to the deletion of streams being sent to it. False otherwise.

Token Acceptance

The SuperAppBaseFlow exposes a virtual isAcceptedSuperToken function, which can be overridden to specify streams of which Super Tokens the Super App's callbacks can react to.

You can forgo it and just use your own functions/modifiers/etc., but using isAcceptedSuperToken is the simplest and most convenient way to set up Super Token acceptance.

 /**
  * @dev Optional (positive) filter for accepting only specific SuperTokens.
  *      The default implementation accepts all SuperTokens.
  *      Can be overridden by the SuperApp in order to apply arbitrary filters.
  */
 function isAcceptedSuperToken(ISuperToken /*superToken*/) public view virtual returns (bool) {
     return true;
 }

Every Super App ought to have functionality to restrict which Super Tokens can trigger callbacks to protect against vulnerabilities from malicious custom Super Tokens.

Callback Functions

onFlowCreated

Override with custom logic that will trigger when a new flow to the Super App is created.

Example from Tradeable Cashflow Example Project

/// @dev override if the SuperApp shall have custom logic invoked when a new flow
///      to it is created.
function onFlowCreated(
    ISuperToken superToken,
    address sender,
    bytes calldata ctx
) internal virtual returns (bytes memory /*newCtx*/) {
    return ctx;
}
ParameterDescription

superToken

Super Token being streamed to the Super App

sender

Address streaming superToken to the Super App

ctx

Contains the context of the stream being modified to the Super App.

The context gets updated when Super Agreement modifications are done in the callback body (learn more). The context must be returned at the end of the callback.

onFlowUpdated

Override with custom logic that will trigger when an existing flow to the Super App is updated.

Example from Growing NFT Example Project

/// @dev override if the SuperApp shall have custom logic invoked when an existing flow
///      to it is updated (flowrate change).
function onFlowUpdated(
    ISuperToken superToken,
    address sender,
    int96 previousFlowRate,
    uint256 lastUpdated,
    bytes calldata ctx
) internal virtual returns (bytes memory /*newCtx*/) {
    return ctx;
}
ParameterDescription

superToken

Super Token being streamed to the Super App

sender

Address streaming superToken to the Super App

previousFlowRate

The flow rate of the sender's stream to the Super App before the latest update.

lastUpdated

The timestamp of when a sender's stream to the Super App was last modified.

ctx

Contains the context of the stream being modified to the Super App.

The context gets updated when Super Agreement modifications are done in the callback body (learn more). The context must be returned at the end of the callback.

onFlowDeleted

Override with custom logic that will trigger when an existing flow to the Super App is deleted.

Example from Borrow Against Salary Example Project

IfonFlowDeleted ever reverts, your Super App will get "jailed" causing its callbacks to no longer trigger in response to stream modifications. So, write youronFlowDeleted code such that it won't revert! Be careful with your logic and think about using try/catches where necessary.

/// @dev override if the SuperApp shall have custom logic invoked when an existing flow
///      to it is deleted (flow rate set to 0).
///      Unlike the other callbacks, this method is NOT allowed to revert.
///      Failing to satisfy that requirement leads to jailing (defunct SuperApp).
function onFlowDeleted(
    ISuperToken superToken,
    address sender,
    address receiver,
    int96 previousFlowRate,
    uint256 lastUpdated,
    bytes calldata ctx
) internal virtual returns (bytes memory /*newCtx*/) {
    return ctx;
}
ParameterDescription

superToken

Super Token being streamed to the Super App

sender

Address of the account streaming superToken to the Super App (or address of the account streaming superToken to the Super App if the Super App is deleting its own flow) *

receiver

Address of Super App (or address of Super App if Super App is deleting its own flow) *

previousFlowRate

The flow rate of the sender's stream to the Super App before the latest update.

lastUpdated

The timestamp of when a sender's stream to the Super App was last modified.

ctx

Contains the context of the stream being modified to the Super App.

The context gets updated when Super Agreement modifications are done in the callback body (learn more). The context must be returned at the end of the callback.

* If a stream is being deleted by the account streaming to the Super App, sender is the streaming account and receiver is the Super App (obviously). However, if the Super App itself is deleting a flow it's receiving, then that triggers onFlowDeleted as well. In this case, it's flipped - sender is the Super App and receiver is the streaming account.

Last updated