Super App Overview

A Super App is a contract which implements agreement hooks.
This mechanism makes it possible to add custom business logic to invocations of agreement actions in an atomic way.

Design Choices

App Jail

Super Apps can be jailed, which means that their callbacks won't be invoked anymore. Basically they stop being Super Apps.

A Super App is jailed if any of this conditions ever happen during its lifetime:

• An invocation of afterAgreementTerminated reverts (this could happen in the context of deleteFlow of the Constant Flow Agreement)
• A callback returns a malformed ctx object
• A callback not supposed to modify ctx does modify it
• A callback does lead to invocation of more nested Super App callbacks than allowed (currently: no nested callbacks allowed)
• A SuperApp with outgoing flows is critical

The jailing happens in the transaction in which any of those conditions is detected.

Main objectives of the jail mechanism:

• make sure that agreements are always destructible (e.g. a Super App can't prevent execution ofdeleteFlow through a reverting hook)
• don't allow malicious or buggy Super Apps to "steal" from borrowed buffers (see About App Credit) more than once
• enforce properly behaving callbacks through rigid rules, being overly protective to users

App Credit

To learn about the app credit system, read here.

App Action

In some cases, it's useful to invoke Super App methods through the Superfluid protocol outside of agreement hooks.
This is the case for example in order to add a Super App operation to a batch call (currently this is the only way to add arbitrary logic to batch calls).
In order for a Super App method to be usable as App Action, it needs to take bytes memory ctx as last argument and take the msg sender (in case it's relevant) from this ctx object.
In About Call Proxies you can learn more about related concepts.

References

• Superfluid public doc about Super apps: https://docs.superfluid.finance/superfluid/protocol-overview/in-depth-overview/super-apps