Protocols start their lifecycle by being added using
protocolAdd(), the same parameters are expected as
protocolUpdate(), except for the
protocolAgentaddress is used in the claims process and is able to withdraw active balance of a protocol.
Once the protocol is added it is expected to deposit an active balance. Once the balance is deposited the premium can be set using
The premium is subtracted from the active balance per second and claimable by the stakers and non-stakers.
The protocol is expected to keep an active balance over time, this requires to call
depositToActiveBalance(protocol,amount)every now and then.
Protocols can lose their coverage in 3 different ways
- 1.Removal by governance
- 2.Removal by arb using insufficient balance
- 3.Removal by arb using insufficient seconds of coverage left
Protocols are still able to submit a claim for 7 days after being removed.
A protocol can be removed by governance at any time. The remaining balance is sent to the
If the active balance of the protocol goes below
minActiveBalance, an arb can call
forceRemoveByActiveBalance(protocol)and receive the remaining balance.
The protocol is expected to keep a balance that's sufficient to keep active coverage for more then
Once the active coverage time gets below
MIN_SECONDS_OF_COVERAGEan arb can call
forceRemoveBySecondsOfCoverage(protocol)to remove the protocol.
The arb will receive x% of the remaining balance. x is calculated using a linear formula starting at 0% and ending at 100% where the starting point is the time when 'coverage left' ==
MIN_SECONDS_OF_COVERAGEand the end point is when 'coverage left' is equal to 0 seconds. This process takes 12 hours and the peak reward will be at the 6 hour mark (50%) as the active balance of the protocol is simultaneously decreasing over time.
This will affect stakers in the core contract, it will not affect non-stakers.
As described above the incentives are in place to remove protocols which have the potential to run higher debt than balance. As this will screw up the accounting. However, it is technically still possible for this edge case to exist: code
If this scenario happens stakers could be negatively affected either way (as it could mint less shares or burn excessive USDC) but the contract tries to withhold the
insufficientTokensby subtracting them from the claimable tokens for the stakers. If that doesn't work, it emits an
insufficientTokens> 0. The contract expects
insufficientTokensto be transferred to the contract to make the accounting work again.