Hubble is obsessed with security. In addition to regular security audits, the protocol performs a wide range of tests on all updates before they are released. Yet, though preventative security measures are heavily emphasized, it is necessary to implement parameters to minimize impact in worst case scenarios.
Net Outflow Caps Explained
Net Outflow Caps serve to limit the loss of funds on the protocol in the case of an exploit. All assets on the protocol, including all collateral types and USDH itself, will have net-outflow ceilings.
These ceilings will be regulated in set time windows, and after each window, the ceiling will reset. Thus, if the outflow cap of a certain asset has been reached, withdrawals will be halted, and will only be resumed in the next window.
In addition to preventing a loss of user funds in the case of an exploit, Outflow Caps also allows the protocol to investigate edge-cases. For example, should a large position be closed and the withdrawal cap be reached, the developers have a sufficient period to investigate the action and ensure that nothing exploitative has occurred.
Net Outflow Caps are determined on an asset-specific basis, and the protocol will remain flexible in changing the parameters of each asset according to balance changes, and user feedback.
Why a “Net” Outflow Cap is Preferable
Net Outflows are a more reliable measure than “gross” outflows, as they more accurately reflect changes to the protocols balance sheet.
If, for example, a single entity deposits $2M BTC on the platform in a certain time window, and 5 other users withdraw $400K BTC each within this same window, the net BTC outflow is effectively zero. In this case, the Outflow Cap will not be triggered.
Note that the developers will still be notified of significant actions on the protocol, such as an unusually large deposit, even if they do not trigger Outflow Caps.
How Net Outflow Caps can Limit Impact of Exploits
One case in which the Net Outflow Cap can prevent a mass outflow of funds is if an Infinite Mint exploit should take place. If this occurs, the exploiter will be able to mint up to a certain amount of USDH in a given window. However, the Net Outflow Cap on USDH will prevent the exploiter from minting an “infinite” amount of USDH, while also giving the protocol time to react.
Initial Parameters for Outflows
Net Outflow Caps will be implemented in 3 areas:
- Each collateral assets
- USDH minted from collateral
- USDH minted from PSM
Caps on Collateral
Collateral outflows will be calculated simply as: Amount of xAsset Withdrawn - Amount of xAsset Deposited.
Initial Cap: $1M for each asset on the protocol
Time Window: 8 hours
Cap on USDH Outflow from Loans
The loan-based USDH outflow parameter will be calculated as: USDH Minted on Loans - USDH Repaid on Loans.
Initial Cap: 2.5M USDH
Time Window: 8 hours
Cap on USDH Outflow from PSM
The PSM-based outflow parameter will be calculated as: USDH Minted from PSM - USDH Burned in PSM.
Initial Cap: 1M USDH
Time Window 8 hours
These parameters are by no means set in stone, and the protocol will remain responsive to user input with regards to the current caps, and time windows. Ultimately, the purpose of Net Outflow Caps is to ensure that users are confident using the protocol, and being reactive to feedback undoubtedly plays a part in this confidence.
To promote the transparency of Net Outflow Tracking, Hubble will be sponsoring a user-driven project to build a dashboard measuring each of these parameters (outflows of collateral, USDH borrowed, USDH minted from PSM).
Deliverables could include:
- Open grafana dashboards
- Stand-alone website monitoring: collateral values, graphs, distance-to-cap
- Alerts via pager duty
Budget up to $30k in USDC and HBB for finished deliveries.
Join the Hubble Discord should you be interested in running the project and/or need some examples of what we are looking for.