Security Practices

Unit tests / Integration tests

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.

Hubble runs several tests for each contract interaction, each instruction and each function. In total, we run 850+ tests on every single code change, and the protocol is continuously adding to it.

Stress tests

Hubble runs 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, the protocol stands by its approach of battle testing its 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.

Hubble is consistently checking for "account validation", and has an automated verification against this vulnerability in its 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 Hubble is not blindsided by such scenarios, we get pre-built libraries to generate random and/or full-permutation test cases for us. The protocol runs 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 Hubble has added to its security framework is limiting per-token capital outflows. To do so, the protocol 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 until the next interval to exploit it again.

For example, if Hubble sets 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. Hubble will implement alerts that monitor when such caps are reached, prompting the protocol to investigate.