Binding Machine Program - Xitadel

1. INTRODUCTION

Xitadel engaged Halborn to conduct a security assessment on their Solana programs beginning on August 5th, 2025, and ending on August 20th, 2025. The security assessment was scoped to the Solana Programs provided in xitadel-svm GitHub repository. Commit hashes and further details can be found in the Scope section of this report.

Xitadel is pioneering a new standard for capital formation in the Web3 space. As a decentralized LTT protocol, it enables projects to issue over-collateralized LTTs - unlocking capital without selling off native tokens or resorting to risky OTC deals. This model offers a structured, compliant, and sustainable path to financing within the decentralized economy.

NOTE: The codebase in scope (xitadel-svm-audit) was provided as a snapshot from the original repository (xitadel-svm) for the purpose of the review. After the fixes were implemented, they were verified in the original repository at the client’s request through the following pull requests: #106

and #125.

It is important to note that only the fixes addressing the findings identified in the audit report were reviewed. Any functionality or changes beyond the verification of these specific fixes are out of scope for this audit. Similarly, any other modifications not directly related to resolving the reported issues are also considered out of scope.

2. ASSESSMENT SUMMARY

Halborn was provided 10 days for the engagement and assigned one full-time security engineer to review the security of the Solana Programs in scope. The engineer is a blockchain and smart contract security expert with advanced smart contract hacking skills, and deep knowledge of multiple blockchain protocols.

The purpose of the assessment is to:

• Identify potential security issues within the Solana Programs.

• Ensure that smart contract functionality operates as intended.

In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were addressed by the Xitadel team. The main recommendations were the following:

• Update the 'activate_ltt' instruction to remove the user supplied 'liquidity' and 'sqrt_price' parameters, and instead compute these values internally.

• Remove the 'Active' arm from the 'refresh_status' function and ensure all transitions from 'Active' occur only via the 'maturate' instruction.

• Add a constraint that verifies the provided 'chainlink_program' account matches the expected Chainlink program ID.

• Require that the entire LP position is withdrawn from the pool and enforce repayment of the full 'token_interest_amount' before allowing the LTT to transition to the 'Matured' state.

• Make 'token_interest_mint' optional during LTT initialization in 'register_ltt'.