Rewards Token Handling
Updated over a week ago

Protocols come in all shapes and sizes. For Protocols with rewards of any kind looking to list on Superform, this guide can help.

Scenario 1: Rewards tokens are reinvested into the ERC-4626 vault

  • Rewards accrued by a depositor are sold for the native vault token and then that is reinvested into the ERC-4626 vault.

Outcome: This is compliant with Superform.


Scenario 2: Rewards tokens are airdropped to the EOA of depositors into the ERC-4626 vault
โ€‹

Outcome: This is compliant with Superform but rewards airdropped to our Superform contract have to be swept to user wallets.


Scenario 3: Rewards tokens are sent alongside withdraw() function to depositor

Outcome: This is compliant as the rewards will end up in the Superform contract and can be swept to users.


Scenario 4: Rewards token are claimable using an external contract by depositors into the ERC-4626 vault

Outcome: This is not compliant with Superform because the Superform protocol cannot call external claim functions.


Scenario 5: Token Rewards are Time-Locked in Escrow
โ€‹

Outcome: Depends.

1) If rewards are airdropped or reinvested into the strategy then its compliant.

2)If the rewards are claimable then its not compliant.

3) If the time-lock is reset based on new deposits or withdraw then its not compliant as Superform's pooled LP model would reset the timer every time a transaction is made effectively locking funds.


Scenario 6: My project has Points.

Outcome: Depends on how those points are measured. The Superform contract that handles users deposits will likely accrue the points. If an external call needs to be made to claim or convert these points then its not compliant.


If your rewards are not compliant with Superform, please reach out to the Superform team if you'd like to discuss how to properly reward your users.

Did this answer your question?