Adaptive Borrow and Withdraw Limits for the Lending Markets of Vires.Finance

Proposal ID
ADdptSo35TcVpqBZqcwHTaRmd5LHXMzPa6pWELJsfmDM

What do we propose:

We propose to establish dynamic limits to prevent large liquidity exits through over-borrowing or withdrawing. This means both borrowing and withdrawing as well as importing and redeeming vTokens will be limited automatically, depending on the level of market utilization.

Why is this important?

Withdrawals of USDC/USDT/USDN are currently blocked because all the USDC/USDT/USDN has been loaned out to borrowers. This means the utilization rates of those markets are above acceptable levels to sustain the protocol. No one was able withdraw because the amount borrowers are paying back in interest is not enough to cover the number of withdrawals. This is why it was prudent to limit withdrawals with the previous proposal to a more manageable 1000 USDT and USDC per day per user.

Now that this admittedly harsh limit is established, we can propose the plan back to full functionality.

By introducing dynamic limits based on utilization rate we can gradually lift (or reapply) withdrawal and borrowing limits automatically as the situation normalizes.

This means Vires users with collateral in the protocol will know when they can withdraw based on the utilization rate. Giving a clear metric to keep track of to understand the health of their positions and the market. it also increases the stability of the protocol by automatically re-enabling limits in the case of extraordinary events that cause a similar liquidity squeeze.

For example, a USDT market that has 250m Borrowable:

|  utilization  | available | utilization, % | withdraw limit | borrow limit |   import |   redeem |
| -------------:| ---------:| --------------:| --------------:| ------------:| --------:| --------:|
|     250M/250M |         0 |           100% |              - |            - |        - |        - |
|   237.5M/250M |     12.5M |          > 95% |             1K |       denied |   denied |   denied |
|     225M/250M |       25M |          > 90% |            10K |       denied |   denied |   denied |
|   212.5M/250M |     37.5M |          > 85% |           100K |         100K |   denied |   denied |
|     200M/250M |       50M |          > 80% |             1M |           1M |   denied |   denied |
|   < 200M/250M |    >= 50M |         <= 80% |       no limit |     no limit |  allowed |  allowed |

Parameters:

The daily withdrawal limit will be: 
 - extended to 10K as utilization drops below 95%,
 - extended to 100K below 90%,
 - extended to 1M below 85%,
 - removed when below 80% utilization;

Borrows will be enabled:
 - when utilization rate drops below 90%;

Importing and Redeeming vTokens (Vires LP tokens) will be enabled:
 - when utilization rate drops below 80%;


This will push the markets to a position of ~80% utilization, which is both a decent APY and a healthy margin for borrows and withdrawals (please note, limiting imports and redeems doesn’t make any sense as users can create multiple accounts).

This proposal sets equal parameters for USDN, USDT and USDC. These parameters, as well as other markets’ configurations, can later be upgraded through Vires DAO.

Transaction Payload

{
  "type": 12,
  "version": 2,
  "data": [
    {
      "key": "limiter",
      "type": "string",
      "value": "3PRBVq52csUvTx77NYwLTULrt2e9jdsHfRB"
    },
    {
      "key": "main",
      "type": "string",
      "value": "3PAZv9tgK1PX7dKR7b4kchq5qdpUS3G5sYT|3PJ6iR5X1PT2rZcNmbqByKuh7k8mtj5wVGw"
    },
    {
      "key": "LimitUtilizationBreakpoints",
      "type": "string",
      "value": "950|900|850|800"
    },
    {
      "key": "34N9YcEETLWn93qYQ64EsP1x89tSruJU44RrEMSXXEPJ_950_acc_limit",
      "type": "integer",
      "value": 1000000000
    },
    {
      "key": "34N9YcEETLWn93qYQ64EsP1x89tSruJU44RrEMSXXEPJ_900_acc_limit",
      "type": "integer",
      "value": 10000000000
    },
    {
      "key": "34N9YcEETLWn93qYQ64EsP1x89tSruJU44RrEMSXXEPJ_850_acc_limit",
      "type": "integer",
      "value": 100000000000
    },
    {
      "key": "34N9YcEETLWn93qYQ64EsP1x89tSruJU44RrEMSXXEPJ_800_acc_limit",
      "type": "integer",
      "value": 1000000000000
    },
    {
      "key": "6XtHjpXbs9RRJP2Sr9GUyVqzACcby9TkThHXnjVC5CDJ_950_acc_limit",
      "type": "integer",
      "value": 1000000000
    },
    {
      "key": "6XtHjpXbs9RRJP2Sr9GUyVqzACcby9TkThHXnjVC5CDJ_900_acc_limit",
      "type": "integer",
      "value": 10000000000
    },
    {
      "key": "6XtHjpXbs9RRJP2Sr9GUyVqzACcby9TkThHXnjVC5CDJ_850_acc_limit",
      "type": "integer",
      "value": 100000000000
    },
    {
      "key": "6XtHjpXbs9RRJP2Sr9GUyVqzACcby9TkThHXnjVC5CDJ_800_acc_limit",
      "type": "integer",
      "value": 1000000000000
    },
    {
      "key": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p_950_acc_limit",
      "type": "integer",
      "value": 1000000000
    },
    {
      "key": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p_900_acc_limit",
      "type": "integer",
      "value": 10000000000
    },
    {
      "key": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p_850_acc_limit",
      "type": "integer",
      "value": 100000000000
    },
    {
      "key": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p_800_acc_limit",
      "type": "integer",
      "value": 1000000000000
    },
    {
      "key": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p_borrow_utilization_threshold",
      "type": "integer",
      "value": 900
    },
    {
      "key": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p_import_utilization_threshold",
      "type": "integer",
      "value": 800
    },
    {
      "key": "DG2xFkPdDwKUoBkzGAhQtLpSGzfXLiCYPEzeKH2Ad24p_redeem_utilization_threshold",
      "type": "integer",
      "value": 800
    },
    {
      "key": "34N9YcEETLWn93qYQ64EsP1x89tSruJU44RrEMSXXEPJ_borrow_utilization_threshold",
      "type": "integer",
      "value": 900
    },
    {
      "key": "34N9YcEETLWn93qYQ64EsP1x89tSruJU44RrEMSXXEPJ_import_utilization_threshold",
      "type": "integer",
      "value": 800
    },
    {
      "key": "34N9YcEETLWn93qYQ64EsP1x89tSruJU44RrEMSXXEPJ_redeem_utilization_threshold",
      "type": "integer",
      "value": 800
    },
    {
      "key": "6XtHjpXbs9RRJP2Sr9GUyVqzACcby9TkThHXnjVC5CDJ_borrow_utilization_threshold",
      "type": "integer",
      "value": 900
    },
    {
      "key": "6XtHjpXbs9RRJP2Sr9GUyVqzACcby9TkThHXnjVC5CDJ_import_utilization_threshold",
      "type": "integer",
      "value": 800
    },
    {
      "key": "6XtHjpXbs9RRJP2Sr9GUyVqzACcby9TkThHXnjVC5CDJ_redeem_utilization_threshold",
      "type": "integer",
      "value": 800
    }
  ],
  "senderPublicKey": "3gQ8QUfoGQW6YVuhUv3zuqsbmxbV5F2FAuDXJqVKD6C9",
  "fee": 50000000,
  "feeAssetId": "WAVES",
  "timestamp": 1651936140000
}
3 Likes

Limiting import/export of LP tokens would make sense if a user has to lock VIRES in able to do it.

You need to refine the steps:

Between 100% and 95% utilization withdrawal limit can be increase from 1k (below 100%) to 2k to 4k to 8k to 10k (below 95%).

1 Like

Why not apply it to all assets? especially when the APR was also limited to 40%

2 Likes

This seems to be a good proposal to vote, but vires community need to know,
in addition to the limits imposed on the basis of available capital,
if there are any changes to the current APY.

BTW i think is too much withdraw limit and will drain all money avaiable too fast

It’s time to return to old APY.

3 Likes

I’m fairly satisfied with making utilization influence everything. I’d vote yes based on this… Except. I don’t see interest being dealt with, I might be blind or dumb. But I don’t see it, and this cap needs to go, so I’ll vote no…

1 Like

You can start a new proposal for this at any time…

In general, i agree, this proposal is very good. Terms are defined for the SC, governance can change those terms by voting. This makes the whole protocol way more transparent and “DAO controlled”. Very much in favor of this!

This is an excellent proposal. Does it fix everything? No, but it doesn’t need to. Remaining issues can be addressed in future proposals. My advice is to vote yes, give it time to work, and make adjustments if required. Nice work, Vires!

The 5% step is too big
The daily withdrawal limit will be:

  • extended to 3K as utilization drops below 97.5%,
  • extended to 10K as utilization drops below 95%,
  • extended to 30K as utilization drops below 92.5%,
  • extended to 100K below 90%,
  • extended to 300K below 87.5%,
  • extended to 1M below 85%,
  • removed when below 80% utilization;

Borrows will be enabled:

  • when utilization rate drops below 90%;

Make other proposal:
Importing vTokens (Vires LP tokens) will be enabled, if there are transactions with a date less than 03.05.2022. And Export will be disabled. Reedem with Withdraw limit.

3 Likes

Good idea, I mean we saw that the limit was good. Adaptive is better. I am in :slight_smile:

The idea is really good, but from my point of view it will not fix the lptokens bot problem taking all the liquidity.

Once import lptokens are back all the liquidity will be drained with bots moving fund to thousands of accounts and we will get back to this FUD and liquidity squeeze.

I have no perfect solution for this problem, but I can see clearly that the above will happen.

The only way I see to avoid it is giving gvires holders priority to withdraw, by doing this bots would need to buy and lock vires to withdraw. Apply this priority only when utilization hits 95%.
(this may not be the best solution, but might avoid all the FUD to happen again)

1 Like

Great proposal but I am in favor of lower withdraw and borrow limits “extended to 1M below 85%” this is huge at 85% utilization rate.

You do understand that, 85% is just 85% tight? If there’s 1000$ supplied, and 850$ borrowed, you got 85% utilization.

Should we only do 10$ a day then? Cuz 1000$ is clearly too much a day, when there’s only 1000 supplied. smh

Import denied at 80%? On starting proposal? Definitely no.
Why not include limits to borrow, import and reendem then?
If idea is inviability users profit in market and lock everyone try this is the patch, then is all right, other side, no.
If the export, import and reendem did created for this, I not know why did created in first place.
Only who have time to wait take advantage of this (yes I will take advantage, but is not fair with others)

I know someone will say, can be change after, can but will not be because is imposed. Last voted did was only informative, memorandum.

I think we are staying with these APYs until the Whale borrower manages to pay down. This proposal should help speed things up, I guess.

My measly 100ish Vires is obviously not going to change anything unfortunately. So if you read before deadline, vote against the top 1… This proposal once again favors debtors. But I guess we should have seen it coming… After all, who rewards people for borrowing to begin with? (Vires apr for debtors is a joke.)

This offer significantly reduces the yield, while the risks remain unchanged, and it is foolish to reduce the yield and introduce withdrawal limits when demand increases. This logic should be the opposite, I vote No.

I love how the whale even bothers to explain themselves like they’re trying to convince anybody and then proceeds to vote with more vires than anybody else can possibly muster to just force their proposal through. Such decentralized! Much DAO!

I guess with all the Vires being bought and locked, Waves insiders probably preparing to uncap interest. Ain’t no one but them buying right now. lolol