Prepared by:
HALBORN
Last Updated 04/06/2026
Date of Engagement: December 30th, 2025 - February 5th, 2026
100% of all REPORTED Findings have been addressed
All findings
32
Critical
6
High
3
Medium
10
Low
8
Informational
5
Alula Finance engaged Halborn to conduct a security assessment on their smart contracts beginning on December 30th, 2025 and ending on February 5th, 2026. The security assessment was scoped to smart contracts in the GitHub repository provided to the Halborn team. Commit hashes and further details can be found in the Scope section of this report.
The team at Halborn assigned a full-time security engineer to assess the security of the smart contracts. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.
The purpose of this assessment is to:
Ensure that smart contract functions operate as intended.
Identify potential security issues with the smart contracts.
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were mostly addressed by the Alula Finance team. The main ones were the following:
Prevent the pool balance from increasing without a proportional issuance of ownership shares, ensuring that every nonzero contribution results in a corresponding share allocation and avoiding scenarios where contributors receive no ownership.
Ensure that the pool balance is decremented by the exact amount of distributed take rate fees whenever fees are paid out.
Ensure that collateral and debt values are always normalized to a consistent internal scale before any health, utilization or liquidation logic is applied.
Restrict market state changes to explicitly authorized actors, requiring approval from a privileged role such as protocol administration or governance before allowing any update to the market state.
Ensure that referrer incentives are fully accounted for by consistently calculating and transferring the corresponding amounts whenever referral fees are charged and by validating that such fees always result in an actual payout.
Update pool liquidity accounting consistently during debt repayment in liquidation.
Require explicit consent from the intended recipient before executing any flash loan, guaranteeing that the receiver has approved the operation or the initiating party and preventing third parties from triggering flash loans without authorization.
Ensure that the oracle price is strictly greater than zero and revert execution when a zero price is returned.
Avoid using spot reserve ratios as an oracle output for value sensitive decisions.
Halborn conducted a combination of manual code review and automated security testing to balance efficiency, timeliness, practicality, and accuracy within the scope of this assessment. While manual testing is crucial for identifying flaws in logic, processes, and implementation, automated testing enhances coverage of smart contracts and quickly detects deviations from established security best practices.
The following phases and associated tools were employed throughout the term of the assessment:
Research into the platform’s architecture, purpose, threat model, and intended user flows.
Manual code review and walkthrough of scoped Soroban (Rust) smart contracts, focusing on cross-contract call flows, authorization boundaries, invariants, and upgrade paths.
Comprehensive assessment of the safety and usage of critical Rust patterns and Soroban primitives (authorization, storage, eventing, and cross-contract invocation) that could lead to logic, configuration, or availability issues.
Local testing using Soroban unit tests and custom PoCs where appropriate.
Automated dependency review via Rust tooling where feasible to highlight ecosystem-level risks and maintenance concerns.
| EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
Critical
6
High
3
Medium
10
Low
8
Informational
5
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Share inflation via donation enables repeated value capture in new pools | Critical | Solved - 02/12/2026 |
| Distributed fees do not reduce available liquidity accounting | Critical | Solved - 02/16/2026 |
| Inconsistent asset value scaling across core protocol operations | Critical | Solved - 02/25/2026 |
| Unrestricted external control of market operational state | Critical | Solved - 02/16/2026 |
| Referrer fees charged but never distributed | Critical | Solved - 03/01/2026 |
| Liquidation repayments desynchronize pool liquidity accounting | Critical | Solved - 02/19/2026 |
| Unauthorized fee draining from flash loan receivers | High | Partially Solved - 01/26/2026 |
| Zero oracle price is accepted as valid and propagated to valuation logic | High | Solved - 02/16/2026 |
| Spot reserve price can be manipulated and used as an oracle output | High | Not Applicable - 02/16/2026 |
| Pool supply limit can be bypassed via donation | Medium | Solved - 02/12/2026 |
| Global protocol state can be irreversibly erased by an administrative action | Medium | Solved - 02/17/2026 |
| Liquidity fragmentation through multiple pools for the same asset | Medium | Solved - 03/01/2026 |
| Multiply pair configuration allows identical underlying assets on both sides | Medium | Solved - 03/01/2026 |
| Reserved fee liquidity can be treated as withdrawable or lendable liquidity | Medium | Solved - 02/17/2026 |
| Swap execution does not allow user defined minimum output protection | Medium | Solved - 02/18/2026 |
| Leveraged deposit can misaccount borrow and referrer fees | Medium | Solved - 03/05/2026 |
| Repay fee can prevent full debt closure in leveraged withdrawal flow | Medium | Solved - 03/05/2026 |
| Leveraged withdrawal can consume tokens already accounted as withdraw fees | Medium | Solved - 03/05/2026 |
| Small collateral deposits can be forcibly removed through bad debt coverage | Medium | Solved - 03/03/2026 |
| Missing validation of transfer amounts before execution | Low | Risk Accepted - 03/04/2026 |
| Centralized market upgrades blocked by misaligned authorization | Low | Solved - 03/01/2026 |
| Unbounded bootstrap configuration can degrade interest accrual and block pool operations | Low | Solved - 02/18/2026 |
| Overlapping bootstrap periods alter liquidity release behavior | Low | Solved - 02/18/2026 |
| Hardcoded external router address reduces integration safety and upgrade flexibility | Low | Solved - 02/18/2026 |
| Liquidations can revert due to negative accrued interest accounting | Low | Solved - 02/19/2026 |
| Swap allows identical input and output tokens | Low | Solved - 02/18/2026 |
| Rounding effects can produce zero token side effects despite positive input amounts | Low | Solved - 03/02/2026 |
| Zero amount operations trigger unnecessary state changes | Informational | Solved - 03/03/2026 |
| Unbounded scarcity fee configuration can block withdrawals | Informational | Solved - 02/12/2026 |
| Simulation path may diverge from actual withdrawal behavior | Informational | Partially Solved - 03/01/2026 |
| State changing operations execute without emitting events | Informational | Solved - 02/17/2026 |
| Unused functions | Informational | Solved - 02/12/2026 |
//Critical
//Critical
//Critical
//Critical
//Critical
//Critical
//High
//High
//High
//Medium
//Medium
//Medium
//Medium
//Medium
//Medium
//Medium
//Medium
//Medium
//Medium
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Informational
//Informational
//Informational
//Informational
//Informational
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
Smart Contracts
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
