Hi,
Totally supportive on this one.
It is currently pretty annoying to have one's vault fully redeemed every 2 weeks or so and have to put back in to get rewards in an infinite loop since most then redeem back on someone else. Loss of time for everyone and bringing 0 value.
I could see as a side effect:

• a short term diminution of iBTC liquidity as self minting vaults might redeem back, but I understand this is not an issue as currently most of it is doing nothing
• a increase of the locked collateral (self minted iBTC somehow swapped for DOT and put as collateral), further reducing APY, which is why I'm definitely not a fan of the extent to which you are willing to cut the vault block rewards. (I definitely get the intent and agree on the concern on sustainability, but find the cut excessive)

@wd9B...grYv

re. the more collateral being locked and impacting APR - this is why the proposal (https://interlay.subsquare.io/post/12) aims to stabilize the Vault income by regularly reviewing and making it easy for vaults/community members to request adjustments.

Great! Then it should be fine to be more moderate in the cut and readjust if the effect is not satisfying? :)

@wd9B...grYv

It all depends on what the community determines as justified and sustainable. See the competitor analysis in
https://interlay.subsquare.io/post/12

I was unable to review the diagram, it does not load. Therefore I could not see what the new game might be. It helps to look at this as a game and see what strategies payers may come up with to maximise their gain.
As far as I can tell, the only change in the model is that you get penalised if you keep your vault "inactive" after self-minting all your iBTC. For the existing vaults, there does not seem to be any new incentive to actually use the iBTC (perhaps reducing risk?). The sniping mentioned above should go away, which is good.

@wd9Y...BDKK View here https://api.ipfsbrowser.com/ipfs/get.php?hash=QmXgHRpwWozFgn5o8Mx5cRZ8AA5Go6yLuG8bB92WU2trkB

As far as I can tell, the only change in the model is that you get penalised if you keep your vault "inactive" after self-minting all your iBTC.
Not really. As a Vault you no longer depend on whether BTC was minted with your Vault in particular - but only on how much capacity you are offering. This also means that self-minting and idling BTC is no longer necessary and in fact less capital efficient.

For the existing vaults, there does not seem to be any new incentive to actually use the iBTC (perhaps reducing risk?).
Minting iBTC in the capacity-based model is only really useful if you plan to use it in DeFi. Additional incentives for Vaults to deploy iBTC in DeFi on Interlay can be launched by the community via governance/network treasury.

I definitely support this capacity-based rewards proposal, since I do think it will achieve Interlay's aims of providing capacity for new users to mint/redeem iBTC/kBTC.

so game theory on the part of vaults ... the way to maximize rewards will be to use the default secure threshold (to maximize capacity) but to redeem against your vault if it actually gets near the secure threshold (increased risk for no direct financial gain). Just keep an eye on median/average collateralization of vaults because once it gets within 20-30% of the secure threshold you'll likely have more inter-vault competition or sniping (this time to eject BTC). Not ideal, but acceptable since most vaults will at least allow some minting via their vaults and vault capacity won't be likely to be filled up until kBTC/iBTC are heavily used.

I'm very confused about why the "weighting between each collateral asset" or LP reward gauge algorithm is necessary at all. As long as the team does threshold assessments, that's the real way to parameterize the reward vs risk for each collateral type. Luckily, all vaults have a unifying equivalency calculation - kBTC/iBTC capacity so you don't really need open market competitive parameters to find a way to equivalently reward operators of vaults with different collateral types. Therefore that feature seems more of a risk to manipulation by larger token holders. I'd recommend the gauges/weighting vs the capacity-based rewards be two completely proposals when put to governance.

@wdCm...tn4a
I'd recommend the gauges/weighting vs the capacity-based rewards be two completely proposals when put to governance

This is helpful feedback!

The concept of rewards based solely on collateral is theoretically good and democratizing. But I see some some significant practical issues that would need to be addressed:

"This simultaneously serves as exit liquidity for vaults who want to withdraw their collateral."

What is the actual mechanic for this exit liquidity? Wont all vaults post collateral to their max comfort level (in order to generate max rewards, which now would accrue regardless of BTC deposited)? If all vaults are at max comfort level why/how would they choose to provide exit liquidity for another vault that needs to withdraw collateral but happens to have BTC deposited? Especially if that vault needs access to that capital quickly. In fact, the other vaults would have a DISincentive to take on this vault's collateral/BTC because - all other things being equal - a vault with ZERO BTC deposited at collateral level N would be better (i.e. nothing to think about) than one that is full at that same collateral level N. Isn't the vault that needs to exit now effectively locked unless it happens to also have enough kBTC to self redeem 100%?

Vaults that are not accepting new issue requests, have zero capacity

Meaning they receive zero rewards? Even if they they are full with BTC? What is the reason for this? Doesn't this compound the problem above? How does a vault manage its collateral risk levels without limiting new issuances/deposits?

@wd9n...dcXA

"This simultaneously serves as exit liquidity for vaults who want to withdraw their collateral."

The assumption of this model is that vINTR holder have a genuine interest in always having some free mint capacity so that the network can grow. If all capacity is used up, assuming rational agents, more rewards should be allocated to vaults to attract additional collateral capital. At the moment, if a vault has no capacity left, it depends on another vaults goodwill to accept the replace request. In the new model, replace request are no longer optional but a vault has to serve them. Why? Because any vault that provides mint capacity is exposed to the risk of a user minting all the remaining capacity (without any option of the vault not fulfilling this mint request) and its rewarded for providing this option. Hence, there is no reason why replace request should have this optionality. Playing 'replace request ping-pong' is an unprofitable option due to the replace fee that will go to the vault that accepts replaces the other vault. So there IS actually an incentives to so, although the vaults don't have a choice anymore.

Vaults that are not accepting new issue requests, have zero capacity
Vaults can set a custom threshold which determines how much iBTC can be minted against their collateral (e.g. their mint capacity). Setting this threshold as low as possible provides maximum mint capacity at a higher risk of 1) having all the collateral locked up and 2) being more likely to get liquidated. The other extreme, setting custom threshold to infinity (=disabling minting) means the vault provides no capacity at all. This is not impacted by the amount of iBTC that was already minted with the vault. E.g a Vault with $2000 collateral and a safe mint threshold of 200% has a mint capacity of $1000. If someone minted $1000 iBTC with that vault, the rewards don't change. Only if the vault decides to either change the amount of collateral or the safe mint threhsold does this impact the rewards.

@wdCm...tn4a

I'm very confused about why the "weighting between each collateral asset" or LP reward gauge algorithm is necessary at all. As long as the team does threshold assessments, that's the real way to parameterize the reward vs risk for each collateral type. Luckily, all vaults have a unifying equivalency calculation - kBTC/iBTC capacity so you don't really need open market competitive parameters to find a way to equivalently reward operators of vaults with different collateral types. Therefore that feature seems more of a risk to manipulation by larger token holders.

Some might vote exactly in that way: treating every collateral asset equally. However, as an example, let's say iBTC can be backed by DOT, SDOT, and stDOT. Some might feel that having the risk of Lido with stDOT is higher and thus rewards for stDOT should be lower than DOT for the same capacity.

Or, let's assume wBTC would be a collateral asset. wBTC opportunity cost is generally lower than DOT assuming BTC and DOT are correlated. So the some might want to decide to reward DOT higher than wBTC.

I'd recommend the gauges/weighting vs the capacity-based rewards be two completely proposals when put to governance.

Those will be different proposal. The first iteration does not differentiate between different collateral assets.

@wd9n...dcXA

What is the actual mechanic for this exit liquidity?

Very good points there! The necessary requirement for this is to make replace request mandatory. So only if vaults are required to take on the other vaults BTC (much like they do when a user issues with them), does this model work. A vault that wants to exit the system would request to be replaced by another vault reserving its collateral, sent the BTC, and have exited the system.

Vaults that are not accepting new issue requests, have zero capacity. Meaning they receive zero rewards? Even if they they are full with BTC?

Yes, they would receive none of the rewards even if they are full with BTC.

What is the reason for this? Doesn't this compound the problem above? How does a vault manage its collateral risk levels without limiting new issuances/deposits?

The accepting new issue request mechanism was really IMO a temporary measure for vaults to control risk. Much better is to set a custom secure threshold: https://docs.interlay.io/#/vault/guide?id=setting-a-custom-secure-threshold
The idea is that even if risk appetite is lower than the system-wide secure threshold, vaults should still provide mint capacity when some of the locked BTC have been redeemed.

Hello,
Some thoughts regarding the vault rewards:

The iBTC liquidity concern might not be valid because the iBTC liquidity that would disappear is false liquidity anyway. I do think the implementation needs a mechanism to prevent full dilution of the vaults APR.

There needs to be a disincentive for an endgame which is a network of big empty vaults consuming all the rewards. The best idea I have is to reward locked collateral at a rate similar to native staking and then additional rewards for locked BTC.

Any kind of rewarding locked DOT is somewhat reinventing liquid staking. Perhaps keeping the present vault reward model and simply adding support for LDOT and similar collateral is the best answer.

Hello! I'm supporting capacity-based vault revenue distribution model.
As a vault, I have repeatedly had to self-issue to keep the rewards after fully draining my vault (redeem request from other vault?). It looked pretty stupid.
I want to urge to consider the issue of mandatory execution of replace requests for vault. This is a way to keep quick access to liquidity. Otherwise, vaults have no incentive to execute replaces, because it reduces their health factor. Thank you.

@wd9n...dcXA
Vaults that are not accepting new issue requests, have zero capacity Meaning they receive zero rewards? Even if they are full with BTC? What is the reason for this? Doesn't this compound the problem above? How does a vault manage its collateral risk levels without limiting new issuances/deposits?

There is a feature that allows you to "deactivate" your vault. If you do that then your Vault will be excluded from the reward pool (even if you have BTC already minted).
If you cannot accept new mint requests because your Vault is full, then ofc you still continue earning rewards. See the VaultCapacity formula.

The better way to manage risk is to set custom collateral thresholds. This has an impact on the capacity and hence the reward share, but it a more flexible tool than hitting "deactivate". The "deactivate" feature was a temporary thing while custom thresholds were not yet available (its main purpose now is to e.g. to run a Vault for experimental purposes).

@coldstoragecap1
There needs to be a disincentive for an endgame which is a network of big empty vaults consuming all the rewards. The best idea I have is to reward locked collateral at a rate similar to native staking and then additional rewards for locked BTC.

This is an interesting point. The problem with rewarding BTC is that this leads to Vaults self-minting BTC that locks up capacity for users who actually want to use BTC in DeFi. We have seen this a lot in the current setup (only 10% of the BTC is actually used, the rest sits in Vaults that are farming rewards).

Agree on trying to find a way to keep incentivizing Vaults to attract BTC liquidity - this will require more modeling and research.

"The better way to manage risk is to set custom collateral thresholds."

Custom collateral thresholds are a good solution to liquidation risk, but they don't address collateral liquidity risk. If it is not possible to immediately exit a vault collateral position, regardless whether there is BTC locked, then the system introduces a very significant risk to that collateral and pushing up the yield that a collateral provider would require.

This assumption: "The assumption of this model is that vINTR holder have a genuine interest in always having some free mint capacity so that the network can grow. If all capacity is used up, assuming rational agents, more rewards should be allocated to vaults to attract additional collateral capital" will operate to alter reward levels over a timeline measured in weeks or more. Maybe.

This is not a practical solution for the management of realtime collateral liquidity risk when it might be needed most by a vault operator that wishes (or more urgently, needs) to exit. Additional rewards associated with locked BTC, however, would mitigate this concern to some extent.

@wd9n...dcXA

Yes. that's why

The necessary requirement for this is to make replace request mandatory. So only if vaults are required to take on the other vaults BTC (much like they do when a user issues with them), does this model work. A vault that wants to exit the system would request to be replaced by another vault reserving its collateral, sent the BTC, and have exited the system.