Back to Discussions
Recommendation for New, Capacity-based Vault Reward Distribution Model
18 Comments

Capacity-based Vault Revenue Distribution

tl;dr.

  • The current Vault reward distribution model is based on how much iBTC has been minted with a Vault.
  • This model presented itself unsuitable, both in terms of fairness, capital efficiency, and benefit to protocol growth.
  • The proposed v2 model hence takes into account iBTC capacity, i.e., how much BTC a Vault can secure, unrelated to how much is already being used.
  • The v2 model focuses on increasing minting capacity for new users ahead of the Interlay 2.0 DeFi hub launch, which aim to onboard significant numbers of BTC DeFi users onto Interlay.

This is a discussion post proposing the new model ahead of deployment to the Kintsugi testnet and as auxiliary information to the Vault block reward adjustment discussion.

The actual activation will require a dedicated governance proposal by the community.

Problem

In v1, Vaults revenue is composed of volume-based bridging fees (mint and redeem) and block rewards in the native INTR token, as operational subsidy while bridge revenue is growing.

Both income streams are distributed among all Vaults, \emph{proportional to how much iBTC was minted with each Vault}.

This model presented itself non-optimal. In absence of BTC liquidity flowing into other parachains due to macroeconomics and slow enactment of unique DeFi opportunities, Vaults are forced to self-mint iBTC in order to earn rewards. This has two negative effects: on one hand, the APR for Vaults is less predictable. On the other hand, the bridge is kept at high capacity without the BTC flowing into DeFi applications: Vaults do not need to take extra risk considering high block rewards, and not all operators are comfortable with DeFi liquidity provision (and they should not be forced to).

Solution

Capacity-based Reward Distribution

The proposal is hence as follows:

Distribute block rewards based on available minting capacity, i.e., locked collateral and the (custom) thresholds, rather than using minted iBTC as basis.

The key benefit Vaults provide to the Interlay ecosystem is for users to be able to mint iBTC and to bridge it back to BTC. This new model hence focuses on incentivizing total mint capacity, i.e., how much iBTC a Vault can back in total.

The total mint capacity of a Vault is measured by the provided collateral divided by the (custom) secure collateral threshold.

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

Vaults with more collateral provided or lower / no custom collateral thresholds provide more capacity overall to the network, taking on a higher risk and thus receive higher fees.

vINTR holders will vote on a weighting between each collateral asset, depending on multiple factors, including risk, benefit to protocol security, and capital cost (also considering external factors).

The same capacity of a Vault with two different collateral assets might result this in a different reward.

The issue, redeem, and replace fees are not affected by this.

The exact model is as follows:

v2 formulas

Expected Impact

This ensures that vaults are incentivized to provide sufficient minting capacity to allow users who want to use BTC in DeFi to mint new iBTC. This simultaneously serves as exit liquidity for vaults who want to withdraw their collateral.

In addition, vaults that are willing to take up a higher risk of being liquidated receive proportionally higher rewards for doing so.

To avoid excessive risk taking, the protocol enforces an lower limit on the collateral threshold that determines the risk for a vault.

This proposal is an important step to scaling the iBTC bridge ahead of the Interlay 2.0 DeFi hub launch, which aims to attract new (BTC DeFi) users to both Interlay and Polkadot as a whole.

Reply
Up 1
Share
Comments

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)
Reply
Up

@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.

Reply
Up

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

Reply
Up

@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

Reply
Up

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.

Reply
Up

@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.

Reply
Up

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.

Reply
Up

@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!

Reply
Up

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?

Reply
Up

@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.

Reply
Up

@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.

Reply
Up

@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.

Reply
Up

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.

Reply
Up

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.

Edited
Reply
Up

@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).

Reply
Up

@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.

Reply
Up

"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.

Reply
Up

@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.

Reply
Up