Prepared by:
HALBORN
Last Updated 09/08/2025
Date of Engagement: September 26th, 2024 - October 7th, 2024
97% of all REPORTED Findings have been addressed
All findings
33
Critical
0
High
1
Medium
10
Low
8
Informational
14
K-BIT engaged our security analysis team to conduct a comprehensive security audit of their smart contract ecosystem. The primary aim was to meticulously assess the security architecture of the smart contracts to pinpoint vulnerabilities, evaluate existing security protocols, and offer actionable insights to bolster security and operational efficacy of their smart contract framework. Our assessment was strictly confined to the smart contracts provided, ensuring a focused and exhaustive analysis of their security features.
Our engagement with K-BIT spanned a 1-week period, during which we dedicated one full-time security engineer equipped with extensive experience in blockchain security, advanced penetration testing capabilities, and profound knowledge of various blockchain protocols. The objectives of this assessment were to:
- Verify the correct functionality of smart contract operations.
- Identify potential security vulnerabilities within the smart contracts.
- Provide recommendations to enhance the security and efficiency of the smart contracts.
| Security analysis | Risk level | Remediation |
|---|---|---|
| Incorrect fee calculation during Pyth oracle interactions | High | Solved - 10/31/2024 |
| Position size validation misplaced | Medium | Solved - 10/31/2024 |
| Inadequate position status and leverage checks | Medium | Solved - 10/31/2024 |
| Unrestricted token address update | Medium | Solved - 11/10/2024 |
| Signature vulnerability due to lack of chain-specific and contract-specific data | Medium | Solved - 10/31/2024 |
| Vulnerability in closePosition due to insecure user signature verification | Medium | Solved - 10/31/2024 |
| Signature replay vulnerability in setFeePercent and registerReferrer | Medium | Risk Accepted - 10/31/2024 |
| Protocol does not account for USDT transfer fees | Medium | Solved - 10/31/2024 |
| Incorrect liquidation price calculation due to leverage rounding | Medium | Solved - 10/31/2024 |
| Inconsistent update timestamp value | Medium | Solved - 10/31/2024 |
| Inconsistent mapping during price submission | Medium | Solved - 10/31/2024 |
| Incorrect loss check during close position logic | Low | Solved - 10/31/2024 |
| Incorrect timestamp comparison | Low | Solved - 10/31/2024 |
| Arbitrage opportunities between different data feeds in trading actions | Low | Risk Accepted - 10/31/2024 |
| Duplicate admin entries allowed | Low | Not Applicable |
| Single-step ownership transfer | Low | Risk Accepted - 10/31/2024 |
| Inconsistent price timestamp validation across oracles and outdated price checks | Low | Risk Accepted - 10/31/2024 |
| Merge operations could be automated during position opening for integrity | Low | Solved - 10/31/2024 |
| Missing checks on submitted price | Low | Solved - 10/31/2024 |
| Insufficient test coverage with mocked oracle interactions and no chain forking | Informational | Solved - 10/31/2024 |
| Unutilized pause functionality and single-role control | Informational | Not Applicable |
| Lack of EIP-1271 support for non-EOA addresses | Informational | Acknowledged - 10/31/2024 |
| Function not callable when paused | Informational | Solved - 10/31/2024 |
| Code duplication in checkPriceDataOrder function | Informational | Not Solved - 10/31/2024 |
| Inefficient gas usage in Pyth price feed updates | Informational | Acknowledged - 10/31/2024 |
| Redundant check call when fetching previous prices | Informational | Acknowledged - 10/31/2024 |
| Underflow in liquidation price | Informational | Solved - 10/31/2024 |
| Redundant margin check | Informational | Solved - 10/31/2024 |
| Late validation checks in `openLimitOrder` function | Informational | Solved - 10/31/2024 |
| Incorrect message for pending limit order status | Informational | Not Applicable |
| Inefficient removal of position | Informational | Solved - 10/31/2024 |
| Redundant check | Informational | Solved - 10/31/2024 |
| Inconsistent profit margin comparison | Informational | Solved - 10/31/2024 |
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
// Download the full report
PerpDex
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
