About App Registry

A super app composes agreements with business logic.

A contract may opt-in to be a super app through the app registry provided in the host contract.

App Whitelisting

In a host contract deployment where APP_WHITE_LISTING_ENABLED is set to true, you will need to provide an non-empty key, or have your app factory whitelisted by the governance.

Notes:

It is currently enabled on mainnets, but we intend to remove it as soon as possible.
- On CELO mainnet, the restriction has been removed.

The app whitelisting guide is available here: https://github.com/superfluid-finance/protocol-monorepo/wiki/Super-App-White-listing-Guide.

There are different ways of having the super app registered:

`registerApp`

It is equivalent to registerAppWithKey with an empty registration key.

This is to reduce the procedural differences between testnet and mainnet super app development.

After deprecating APP_RULE_REGISTRATION_ONLY_IN_CONSTRUCTOR and the registration key usages, registerApp becomes the preferred method again.

(Deprecating) `registerAppWithKey`

You must obtain a registration key for networks where APP_WHITE_LISTING_ENABLED is set.
registerAppWithKey is meant to be used by an EOA, in fact the tx.origin of the app registration transaction must be whitelisted (checked via getAppRegistrationConfigKey of the governance contract.)
- This is called the APP_RULE_REGISTRATION_ONLY_IN_CONSTRUCTOR rule. The intent for this rule is to prevent a contract from upgrading itself to Super app after the fact. Retroactively, APP_RULE_REGISTRATION_ONLY_IN_CONSTRUCTOR is more on the nanny-state rule side, since it tries to protect users from malfunctioning or malicious Super apps.
Each key should also carry an expiration date specified in getAppRegistrationConfigKey.
- The design purpose of the key is to allow whitelisting process to have "finer control" over the same EOA.
The smart contract that calls the registerAppWithKey must be in its constructor.
- It is defensive rule to prevent a "smart contract" to become a super app after a period of time, which may confuse or even take advantage its users.

(Deprecating) `registerAppByFactory`

registerAppWithKey has a fundamental limitation: for a use case where many new functionally-equivalent super apps need to be spawned, it is simply not possible, due to the APP_RULE_REGISTRATION_ONLY_IN_CONSTRUCTOR rule.

To address that a more relaxed rule is introduced to allow a known factory contract to be whitelisted by the governance (getAppFactoryConfigKey governance method), so that the factory contract can have unlimited quota to create new super apps.