RewardedUpgrader: Incentivized auto-topup mechanism

[d10r]

Rationale

Most Super Tokens are ERC20 wrappers.
As long as Super Tokens aren't ubiquitous, users will often need to upgrade/downgrade in order to shift between ERC20 and Super Token representation.
This liquidity splitting increases the risk for streams to be liquidated due to insufficient balance on the Super Token side.
Having to manually watch and shift liquidity is cumbersome. Being liquidated is relatively expensive and re-opening the stream is cumbersome and may in some cases not undo actions triggered by a steam having been liquidated (because of the latter, some users may be willed to pay even more than the deposits at risk for such a service).

In order to mitigate those pain points, we can provide a system which automates the shifting of liquidity from ERC20 to Super Token.

Basic Idea

We deploy a contract which provides a default implementation for permissionless, incentivized auto-topup.
In order to subscribe to the service, users only need to give ERC20 approval for the underlying token to this contract.
A PoC implementation of such a contract can be found here.

The contract converts ERC20 tokens of the user to Super Tokens. The transactions which do so can be triggered by anybody.
The transaction executor (keeper) gets a reward.
Permission to upgrade is given only if the account is close (defined as multiples of the liquidation period) to being critical. The reward for the top-up transaction is inverse linearly proportional to the time remaining until critical (thus max reward just before the account gets critical).

This could probably be simplified further by always giving permission to upgrade, but would require a different/additional rule for the reward.
In any case, the time window should probably be much larger, e.g. 1 month.

Keepers doing the transaction have to:

• Listen for ERC.20 Approval events to the contract
• Keep track of relevant accounts and their current reward potential
• Trigger a tx if the current reward potential for an account reaches their defined threshold for doing so (a default implementation should be such that multiple entities running it won't trigger such a tx at the exact same time, e.g. by not defining a default value for a parameter influencing it)

Ability to be a keeper for this system could be integrated in the reference sentinel implementation.
In this case there's also an option to add a 3Ps like mechanism with a stake-secured priority period.

The contract could likely also be implemented such that generic keeper networks like Gelato can run it.

To be done for a rollout (MVP)

• Finish spec (especially reward design)
• Implement contract and tests
• Provide a backend system/integration, at least one of
  • Dedicated implementation
  • Sentinel integration
  • Integrate with generic keeper networks
• Deploy contracts and add their address to networks list
• Provide instructions / a frontend / Dashboard integration for users
• Provide instructions for keepers