KalqiX Smart Contracts Audited by Hexens: Zero Critical, Zero High Findings

Infrastructure that holds real value needs to be verifiable. Here's what happened when we put our contracts under one of the best security firms in the space.

Building ZK-powered exchange infrastructure means one thing above everything else: the contracts that handle user funds must be airtight. No shortcuts. No assumptions. That's why we engaged Hexens, one of the most respected smart contract security firms in the blockchain industry, to conduct a full security review of our DEX Bridge and ZK Contracts.
The audit is complete. The report is public. Here's everything you need to know.

Who Is Hexens?

Hexens is a blockchain security firm known for deep, adversarial smart contract audits across some of the most complex protocols in DeFi. Their team has audited infrastructure across ZK systems, bridges, and rollup contracts, which is exactly the territory KalqiX operates in. The review was led by Kasper Zwijsen, Head of Audits at Hexens.
This wasn't a checkbox audit. It was a week-long, code-level security review of the contracts that power KalqiX's bridge and ZK verification layer.

What Was Audited

The scope covered the KalqiX smart contract codebase at a specific commit on our GitHub repository, focusing on two core components:

KalqiXBridge.sol is the bridge contract handling deposits, withdrawals, emergency exits, priority exits, and asset accounting across L1 and L2.

KalqiX.sol is the core protocol contract responsible for ZK proof verification and block finalization via the `verifyBlock` function.
These are the contracts that sit between user funds and the KalqiX ZK infrastructure layer. Getting these right is non-negotiable.

The audit ran from 18 December 2025 through 13 January 2026, with an initial report delivered on 29 December 2025, revisions received on 5 January 2026, and a final report signed off on 13 January 2026.

The Results

9 total findings. Zero critical. Zero high.

Every medium severity finding was fixed and validated by Hexens before the final report was issued. Every informational finding was addressed. Both acknowledged findings were low severity with rare probability, and one of them reflects a deliberate design decision explained below.
Hexens confirmed in their report: "We can confidently say that the overall security and code quality have increased after completion of our audit."

What Was Found and What We Did About It

Medium Findings (All Fixed)

KALQ1-1: Deposit cancellation leads to accounting desync
When a deposit was cancelled during emergency mode, the `cancelDeposit` function was not decrementing the `tokenVsDeposits` mapping, which is the internal tracker for total deposited amounts per token. This could cause a valid deposit to incorrectly trigger a `BreachingMaxDepositAllowed` revert even when the actual deposited amount was within limits.
Fix: A single decrement line was added to `cancelDeposit` to keep accounting in sync.

KALQ1-3: Priority exit requests can cause temporary DoS
The `requestPriorityExit` function was adding entries to the priority exit queue without verifying the caller's actual token balance. An attacker could theoretically flood the queue up to the `maxUnprocessedPriorityExits` limit, temporarily blocking legitimate users from submitting priority exit requests.
Fix: A minimum ETH fee requirement was added to make spamming the queue economically unviable.

KALQ1-4: Forced exit leads to accounting desync
The `forcedExit` function is used during emergency state to allow users to withdraw via JMT (Jellyfish Merkle Tree) proof. It was transferring tokens out without decrementing the `tokenVsDeposits` mapping. This created an accounting mismatch where the contract believed more funds existed than actually did, which could cause valid `claimAsset` calls to fail for users with correct merkle proofs.
Fix: `tokenVsDeposits` is now decremented after each successful forced exit transfer.

Low Findings

KALQ1-10: Missing token validation in requestPriorityExit
Status: Fixed. The function was not verifying that the provided token address matched the registered asset config, which could allow requests with unregistered tokens to pass validation under a specific configuration. Explicit token validation was added.

KALQ1-6: ERC20 bridge does not reject sent ETH
Status: Fixed (reclassified as Informational in the final report). When bridging ERC20 tokens, the `bridgeAsset` function accepted `msg.value` without checking if it was zero. Any ETH accidentally sent alongside an ERC20 bridge call would be permanently locked. A `require(msg.value == 0)` check was added for non-native token deposits.

KALQ1-5: Funds could be permanently lost when cancelling deposits
Status: Acknowledged (design decision). Hexens flagged that `cancelDeposit` refunds to `deposit.to`, which is the L2 destination address rather than the original `msg.sender`. In edge cases involving contract addresses or intent-based deposit systems, this could result in funds going to an incorrect address.
Our team's position: `bridgeAsset` allows anyone to deposit on behalf of any user, with the destination address being the intended beneficiary. Refunding to `msg.sender` instead could cause funds to be returned to an intermediary rather than the actual user. This is particularly relevant for intent-based systems built on top of KalqiX. We acknowledged the edge case and have added documentation to flag this behavior to integrating protocols.

KALQ1-8: Minimum withdrawal change could lock users' exits
Status: Acknowledged. If the `minWithdrawal` config for an asset is increased after a user initiates an exit, the user's `claimAsset` call could permanently revert. We have acknowledged this as a governance risk and will ensure minimum withdrawal parameters are managed with care. Decreasing minimums will always be permissible; increases will require careful timing consideration.

Status: Acknowledged. If the `minWithdrawal` config for an asset is increased after a user initiates an exit, the user's `claimAsset` call could permanently revert. We have acknowledged this as a governance risk and will ensure minimum withdrawal parameters are managed with care. Decreasing minimums will always be permissible; increases will require careful timing consideration.

Informational Findings (All Fixed)

KALQ1-7: Read-only reentrancy of tokenVsDeposits
Status: Fixed. The `claimAsset` function was updating `tokenVsDeposits` after the ETH transfer rather than before, creating an intermediate state where external contracts querying `tokenVsDeposits` during the callback could read a stale, inflated value. Fixed by following the CEI (Checks-Effects-Interactions) pattern so state is updated before the transfer executes.

KALQ1-9: Redundant priority exit root query when count is zero
Status: Fixed. A minor gas optimization. The `verifyBlock` function was querying `priorityExitVsRoot` from the bridge even when `_processedPriorityExitCount` was zero, then immediately overwriting the result. Fixed with a simple conditional to skip the unnecessary cross-contract call.

Why This Matters for KalqiX Partners and Integrators

KalqiX is infrastructure. DEXs, perpetuals protocols, and DeFi applications build on top of us. That means the security of KalqiX's contracts directly determines the security of every protocol in our ecosystem.
Zero critical vulnerabilities. Zero high severity findings. Every medium severity issue, the ones with real operational impact, was fixed and validated before mainnet. That's the baseline every infrastructure layer should hold itself to.
The full audit report is publicly available on Hexens' website and on their GitHub. We publish this not as a marketing exercise but as a matter of protocol transparency. Our partners deserve to read the report themselves.

Full report: [Here]

PDF: [GitHub, Hexens Public Reports]

KalqiX is the ZK-powered Central Limit Order Book infrastructure layer for on-chain exchanges. DEXs, DeFi protocols, and L1/L2 chains build on KalqiX to access institutional-grade order matching, zero MEV, and cross-chain liquidity without building it themselves.