Security Practices

Hubble Protocol - Official Documentation

Use Hubble Protocol Join the Discord Twitter Blog

Search…

Security Practices

Unit tests / Integration tests 
This is the meat of our testing. These are tests that check individual "functions" in the codebase, or entire "workflows". Essentially, scenarios are generated in which users perform certain actions, and we check that the code performs as intended. 
We run several tests for each contract interaction, each instruction and each function. In total, we run 850+ tests on every single code change, and we're continuously adding to it.
Stress tests 
We run tests involving hundreds of users and actions to see how the smart contracts would evolve at scale. For instance, what if there are thousands or millions of liquidations? These are the kinds of scenarios we run tests on. However outlandish it may seen, we stand by our approach of battle testing our contracts to ensure resilience.
Security tests 
Solana has a particular vulnerability that was exploited in the past, which failed the "account validation checks." To summarize, if the program doesn't check whether the inputs into the instruction are correct, a hacker could disguise a malicious input to seem correct at face value, enabling them to steal user funds. 
We are consistently checking for "account validation", and have an automated verification against this vulnerability in our testing framework. Almost every single input is checked against malicious inputs in three ways: 
"Actual tests"
"Anchor constraint checks"
"Soteria tests"
Soteria audit tool 
Soteria is a tool that provides automated testing for regular exploits. We run the Soteria tests on every "commit" in our code base. Soteria checks for account validation failures, as well as math failures. 
Example output:
js
detected 0 untrustful accounts in total.
detected 0 unsafe math operations in total.
Property based tests / Generative tests and fuzzing 
Typically, people test the scenarios they can mentally conceive: good cases, bad cases, edge cases etc. However, there are always "unknown unknowns." To ensure that we are not blindsided by such scenarios, we get pre-built libraries to generate random and/or full-permutation test cases for us. We run this for math operations, staking calculations, and wherever else it makes sense.
Deposit Caps
To ensure the protocol stays solvent, Hubble enforces deposit caps on different kinds of collaterals, as well as global and per/user debt ceilings.
Withdrawal flow caps (code audited, unreleased)
Another layer we are adding to our security framework is limiting per-token capital outflows. To do so, we will limit how much value (collateral, USDH) can leave the system by hourly intervals. As such, if an exploit is possible, there is a measure of damage control, and the hacker would have to wait to the next interval to exploit it again. 
For example, if we set a 4-hour interval, with a USDH outflow cap of 5 million, a hacker would be able to withdraw a maximum of 5 million USDH from the system within that interval. We will implement alerts that monitor when such caps are reached, prompting both the team and the community to investigate. 
Note: This remains unreleased, and the caps will have to be agreed upon by the community.

FAQ - Previous

Security and Team

Security Audits

Last modified 27d ago

Copy link

Outline

Unit tests / Integration tests

Stress tests

Security tests

Soteria audit tool

Property based tests / Generative tests and fuzzing

Deposit Caps

Withdrawal flow caps (code audited, unreleased)