Net-outflow ceilings

Ensuring the security of the protocol’s code is a high priority for the Hubble dev team. Thus far, the team’s efforts have gone into the prevention of exploits, doing code reviews upon code reviews, and conducting numerous external audits. Preventing exploits is the first priority when it comes to security.

It’s both a core value of the team and respect and care for user’s funds.

However, as has once again become evident in recent months, exploits do happen. Therefore, the team believes that, beyond prevention, we need to implement safety measures to ensure the safety of user funds, should the worst happen.

The Net-Outflow Ceiling

If an exploit does occur, it is necessary to ensure that this cannot lead to an exodus of user funds, that it is slowed down, at least. To prevent this, we propose to implement a net-outflow ceiling across all assets on the protocol, including all collateral types and USDH.

Each asset will have an individual ceiling parameter, and the calculation of outflows will be reset at the end of each time-window. This gives the protocol flexibility to assess the necessary parameters for each asset according to current statistics, which can be adjusted over time. The time-windows also allows the team to investigate outlying cases when, for example, a user closes a position worth millions on a single asset and withdraws all of their collateral.

The ceiling will thus act as a blocker when a certain threshold of net-outflow of funds has been reached within a certain timeframe. Net outflows will serve as a better benchmark than gross outflows, as this is an indicator of changes in the protocol’s balance sheet.

If, for example, a user deposits $2 million in collateral, and 10 other users withdraw $200,000 each, there are effectively no net outflows, and thus nothing out of the ordinary (note, however, that the team will also be notified when actions with a significant impact on the protocol balance sheet does take place).

An example of how the ceiling could prevent a drain of protocol funds is if an infinite mint exploit were to take place. If there is an infinite mint, and the exploiter brings vasts amounts of USDH to the protocol to exchange for UST via the PSM, a net-outflow of UST will prevent the exploiter from draining the entire UST reserve in the PSM.

Parameters

As mentioned earlier, each asset will have its own ceiling. These ceilings will reset in 4 hour windows, with 6 windows per 24 hours.

The calculation for the net outflow of each asset will simply be: xAsset deposited - xAsset withdrawn

The calculation for the net outflow of USDH will be split in two, each with its own parameters. Firstly, net outflows for borrowing: USDH borrowed via Loan - USDH Repaid on Loans

Secondly, net outflows for the PSM: USDH minted from PSM - USDH burned in PSM

For the initial implementation of the ceilings, we propose a net outflow of $3 million per asset/component, including USDH. This is subject to discussion, and can also be adjusted as the protocol evolves and more collateral is deposited/USDH minted on a regular basis.

Feedback

The purpose of this proposal is to gather input on what you think the ceiling parameters for each asset should be, as well as to get feedback on where you as users might see possible deficiencies in this implementation that might still be susceptible to exploits.

Need help

If any of the community members is willing to create a dashboard calculating net outflows per token type per day/time window to help inform the decision, the Hubble protocol is willing to sponsor the project.

Please give your feedback below.

4 Likes

Awesome initiative!

Probably an AI/ML or other algos to judge the ceiling parameters, combined with manual monitoring? Then initiate a lockdown.
Meaning, based on abnormal activities. Sure by now y’all have a history of inflows/outflows, borrowing, loans, or any outliers dataset.
Would love to collab if a community dev wanna build it.

Looks like Impossible Finance is doing something similar, just open source: