Solvency Incentive Ratio

In decentralized protocols, tokens are used to incentivize behavior. In Bitcoin, miners maintain the network, facilitate transactions, and are rewarded BTC for doing so. On Compound, borrowers and lenders are incentivized with COMP based on the utilization of each market. Similarly, Tranche incentivizes users with SLICE tokens, with the ultimate objective of maintaining the solvency of the individual tranches and the protocol as a whole.
SLICE Distribution Objective
Outside SLICE staking which incentivizes holders to lock-up SLICE and provide liquidity on Uniswap, the platform distributes SLICE to Tranche holders across markets. The key objective of this distribution is to ensure that the tranches remain solvent.
Designing a Framework to Maximize Solvency
To design a framework that satisfies this objective, we have to better understand the relationship of solvency against the parameters of the tranches. The sections below map out the scenarios.
Scenario 1. Fixed Rate < Underlying Rate
In scenario 1, everything is functioning as expected. The protocol has defined a reasonable fixed rate for Tranche A, and the underlying rate is in excess of it.
In this scenario, as Tranche A deposits increase, Tranche B APY increases (as well as ΔAPY). Also, as Tranche B deposits increase, APY decreases as returns must be shared amongst a greater group of participants. This decrease levels out at the underlying protocol’s return.
As Tranche B deposits increase, Tranche B Yield approaches the underlying protocol's return
For this reason, we want to ensure that SLICE rewards are distributed to Tranche A holders, to maximize APY returns for Tranche B (ΔAPY). Similarly, we want to ensure fewer Tranche B holders, so that returns are distributed among fewer participants and as a result, also maximized. That being said, the increase in Tranche B participants does not reduce the overall solvency, only the Tranche B yield. For this reason, we also distribute rewards to Tranche B, albeit a lesser amount.
Result: Rewards mostly distributed to Tranche A
Scenario 2. Fixed Rate > Underlying Rate
In scenario 2, the protocol cannot meet the Tranche A fixed rate from the underlying protocol and must leverage Tranche B returns/holdings to do so.
In this scenario, as Tranche A deposits increase, Tranche B APY suffers, as more and more value is needed to fulfill the fixed rate obligation. That being said, as Tranche B deposits increase, the APY is improved, as more participants burden the fixed rate obligation. 
As Tranche B deposits increase, yield approaches zero, as the losses are incurred by more participants
For this reason, in this scenario, we want to minimize Tranche A deposits to zero and maximize Tranche B deposits, to reduce the losses incurred by Tranche B holders. In this case, losses disrupt the solvency of the system.
Result: Rewards completely distributed to Tranche B
SLICE Rewards
Now that we understand how solvency is maximized we can design a rewards system that incentivizes this outcome.
SLICE Rate: The first parameter to define is the overall rate of SLICE distribution. How much SLICE are we distributing per block (day, week, or year). This is a constant value set through Tranche Improvement Proposals (TRIPs).
Distributing by Market Size (Market Rate): The SLICE rewards then need to get distributed across markets (e.g. aDai or cETH). To ensure the rewards are distributed evenly we use the market size in relation to the total deposits. So if there is $100 locked in the cDai market, and there is $1,000 locked in the Tranche protocol, we expect the cDai Market Rate to be 10% of the SLICE Rate (100/1000).
Distributing by Tranche Solvency: Finally, we have to distribute the Market Rate across the tranches in such a way that maximizes solvency based on our understanding of how solvency changes with our protocol parameters. We need to distribute rewards to Tranche A and B in a proportion that maximizes Tranche B APY (ΔAPY). We define the optimum ratio as the “Solvency Incentive Ratio”or SIR.
Solvency Incentive Ratio (SIR)
This is defined the ratio of SLICE rewards distributed to Tranche A. In the section below, we’ll do a walkthrough on calculating it.
Tranche B Return - you can learn more about how Tranches are calculated in our docs. trancheBReturn = (totalTVL * (1 + extProtRet) - trATVL * (1 + trARet) - trBTVL) / trBTVL 
Delta APY -  the difference between the “external protocol return” and Tranche B return.
DeltaAPY = extProtRet - trancheBReturn
Delta APY % - we translate the Delta APY to be a percentage of the external protocol return:
DeltaAPYPercentage = DeltaAPY / extProtRet
Balance Factor - we then add a balance factor that skews rewards in a particular direction. In the SLICE rewards graph below it adjusts the horizontal asymptote.
trBPercentage = DeltaAPYPercentage + balFactor
Tranche B Rewards - we can then multiple this percentage by the Market Rate to calculate the SLICE distribution per block for this Tranche.
trBSliceRewards = trBPercentage * dailySliceAmount
Calculating the Solvency Incentive Ratio - finally, since the SIR is defined as the SLICE rewards allocated to Tranche A, this is calculated as:
trASliceReward = dailySliceAmount - trBSliceRewards
SolvencyIncentiveRatio = trASliceReward / dailySliceAmount
Relationship between Tranche Deposits and SLICE Rewards
Now that we have mapped out our calculations, we can visualize the relationship between Tranche Deposits and SLICE Rewards for both tranches on one graph:
As Tr. A deposits grow, their SLICE share increases and plateaus - Tr. B is inverted
We can notice that the two lines have a horizontal asymptote that can be manipulated with the balance factor (the larger the balance factor, the greater the share of B rewards, so the asymptote moves down).
SLICE Controller Contract
For more information on the SLICE rewards controller contract, please visit this repository.
Display in Tranche App
From a front-end perspective, users can see the Underlying Protocol Return,  Tranche Return as well as the SLICE return.
SLICE APY appears on Tranche Finance App with TBD placeholder