< Back to Blog

JetGovern Audit Announcement and Patched Bug Disclosure

As exciting as the burgeoning DeFi industry can be, it is not without risk. Jet Protocol’s top priority is the security and safety of users, and we are committed to ensure that these standards are upheld as highly as possible. While Jet’s mission is to strive and push the envelope of DeFi and deliver groundbreaking and useful DeFi primitives, this cannot be done in good conscience without a serious approach to safety and minimizing risk.

As Jet begins to press into new DeFi territory with the upcoming margin and bonds products, a carefully crafted process assuring security becomes even more important. To that end, the core team has engaged multiple auditing firms and selected two that showed the utmost professionalism, skill, and turnaround time – OtterSec and Halborn.

The imminent JetGovern application contains code for voting, staking, and airdrop. The security of this application is paramount, due to the critical multipurpose nature of this release and its primary relationship to the JET holders who will ultimately guide the protocol through staking and voting. OtterSec has already completed the stage 1 audit for this code and we are currently awaiting their stage 2 report.

What did the audit entail?

The full external auditing process is as follows:

  1. The code is “frozen” and handed off to the OtterSec team for the stage 1 audit. No more changes may be made at this point without compromising the audit. (this is complete ✅)
  2. OtterSec comes back with an audit report describing vulnerabilities ranging from critical to low severity. They also present general findings of code design patterns and make observations and suggestions about how this could be improved, even if these patterns do not lead to any vulnerabilities. (this is complete ✅)
  3. Jet engineers address the issues presented and change the code to patch the vulnerabilities and follow best practices. (this is complete ✅)
  4. The updated codebase is handed off to OtterSec again for the stage 2 audit; a final pass to assure that the code is safe and ready to ship! (we are here 👍)
  5. The ensuing stage 2 audit report will be made available for all to view on the JetGovern application and in the docs. (🔜)

What did we find?

In the early days of Jet, we flew low and under the radar. We deliberately elected to not draw unnecessary attention to the protocol as we tested it under various conditions. We moved fast, and as a result, engineering inefficiencies were exposed publicly; giving us a strong tailwind to improve our internal audit and deployment processes. On January 23rd, Charlie You from Castle Finance reached out after discovering a vulnerability in the V1 codebase. The submission stated that because withdraw_tokens didn’t work as expected, a user could deposit but not withdraw tokens. Upon review by Jet core engineers, it was noticed instead that you could withdraw tokens as long as the notes were owned by the program authority, so not only was it broken, it was broken in a way that would have allowed anyone to withdraw any deposit. Jet core engineers quickly patched the bug; no users were affected.

What have we done about it?

Even though no users were affected, Jet cannot and will not rely solely on whitehat hackers. Jet engineers now follow an extensive, stringent audit process internal audit procedure (including report writing) before even handing anything off to external auditors.

  • The codebase is audited internally by a minimum of 2 core protocol devs that previously haven’t contributed to the module under audit, producing a detailed report analyzing all functions for security issues.
  • This report along with all relevant code documentation is handed off to our primary auditor – since we have engaged both OtterSec and Halborn, the primary auditor of each codebase will vary. In the case of jet-governance and jet-margin, OtterSec is the primary auditor and is conducting its external audit.
  • Jet core engineers and the auditor iterate on the codebase until the auditor verifies that they believe all discovered vulnerabilities have been resolved.
  • The devnet “baking” period begins, occurring for a minimum of 2 weeks. This is a period where the code is deployed on devnet and becomes eligible for bug bounties. This also allows projects to begin planning integrations with Jet Protocol.

The Jet MVP was a testbed aircraft; Jet V2 is a production aircraft fit for commercial service. With the quickly-upcoming JetGovern release, the airspace for community-led governance will open and begin to take effect. The existing collateral types available on Jet will be assessed and re-approved according to the process laid out in the collateral onboarding framework. Quickly thereafter, it is expected that the forum posts applying to be new collateral types will also follow the onboarding framework and be put to vote. And that’s just the beginning – The future is bright!

< Back to Blog