Testing Sagittarius 0x*

Gm Convergers,

Now that the audit has been engaged (https://twitter.com/Convergence_fi/status/1651176811747766275), it may be the right time to share more details regarding the testing process that we have conducted prior to audit. If audits are crucial when it comes to security, tests are necessary to insure that the protocol’s functions will behave as expected, especially under certain conditions (limit cases). To be able to do so, we have set up a particular and probably unique testing environment, thanks to a solution called Ethernal (https://tryethernal.com/).

Testing environment

Usually, protocols are being tested on public testnets. It works, without any doubt. However, using a testnet doesn’t give full control over the testing environment. It can be painful to get ETH from faucets, and you’re basically stuck in time. It doesn’t forbid to test time-based functions, but the tricks to do so are not convenient.

Thus, instead of performing tests on Goerli or Sepolia, we decided to fork the mainnet, with Ethernal deployed on top. Running our own blockchain allowed us to act as admins over it, while working in a certified “ISO” environment. Being completely masters of the forked mainnet is also way more convenient to test time-related behaviors, as we can perform time jumps effortlessly.

Then, we deployed Ethernal as a block explorer on top of our private network. Ethernal is basically an Etherscan-like solution that can be deployed on top of any EVM blockchain. In simple terms, it allowed us to track every transactions and to interact with contracts just as we would do with Etherscan.

To summarize, on this private testnet, we can:

• Restart the blockchain over and over when needed;
• Perform time jumps to test time-based functions;
• Track every tx in details;
• Interact with contracts easily.

Then, all we had to do was to deploy our frontend, add our network to MetaMask, and perform tests in a friendly and efficient environment!

Testing process

Once we had everything properly set, our goal was to write test frameworks that would allow us to stress test every behaviour of the protocol, from bonds and staking to locking and voting. The method we established was straithforward:

1- We established test scenarios based on statics and dynamics inputs,

2- We performed every actions directly on the frontend,

3- We time-jumped as many time as needed (and performed actions when needed according to our scenarios),

4- We compared onchain outputs to expected results (amounts of rewards, gauges weights, locked tokens balances etc).

Scenarios have been designed to replicate potential limit cases and erratic behaviors. If contract safety was of course a concern during the test campaign, the purpose was mainly about insuring that the logic was good, mostly regarding various computations. Once every framework has been passed successfully, we also tested by performing random actions (not following any predefined scenario) in an attempt to generate bugs or unexpected behaviours.

Using such a method had us find some malfunctions along the process. We then proceeded by iterations, fixing bugs and retesting until every framework was fully validated.

Below are some examples of what our test frameworks look like:

In addition to these tests, a fuzzing will be perform by Halborn during the audit process, giving us additionnal insights about the robustness of the contracts’ logic. Audit is expected to be completed by the end of May.

If all this process doesn’t guarantee in any way that our contracts are not vulnerable to exploits, it gives us a fairly high degree of certainty that the logic behind contracts has been properly coded, and match expectations.

Well, that’s all for now, anon. Once again, thanks for reading. Stay safe, and long live Convergence!