Prepared by:
HALBORN
Last Updated 12/08/2025
Date of Engagement: October 20th, 2025 - October 24th, 2025
100% of all REPORTED Findings have been addressed
All findings
8
Critical
0
High
1
Medium
1
Low
1
Informational
5
THORChain engaged Halborn to conduct a security assessment of the Ghost Vault smart contract, beginning on October 19th, 2025 and ending on October 23th, 2025. Commit hashes and further details can be found in the Sources section of this report.
Ghost Vault is a CosmWasm-based lending and borrowing protocol designed to operate on top of the Rujira ecosystem. It enables users to deposit native assets into a vault and earn interest, while allowing borrowers to draw liquidity against those deposits. The protocol maintains two internal accounting pools (a deposit pool and a debt pool) and determines interest rates dynamically based on real-time utilization ratios. Interest accrual is applied linearly over time, and all interactions (deposits, borrows, repayments, withdrawals) trigger synchronization of the accumulated interest between pools.
The team at Halborn assigned a full-time security engineer to evaluate the security of the smart contracts. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract auditing, and deep knowledge of CosmWasm and other Web3 ecosystems.
The purpose of this assessment is to:
Ensure that core vault functions operate as intended and maintain consistent accounting between depositors and borrowers.
Identify potential vulnerabilities or logic flaws in the interest calculation, liquidity management, and share issuance mechanisms.
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were mostly addressed by the Rujira team. The primary recommendations were the following:
Convert overpayment shares back to base tokens before refunding to ensure accurate user reimbursements.
Enforce borrower limits in base tokens instead of shares to prevent exceeding the real debt cap.
Apply interest in chunks and update last_updated incrementally to avoid persistent DoS after long idle periods.
Reject or accumulate tiny deposits that would mint zero shares to prevent silent value donation.
Add a hard APR cap to prevent extreme rates or unsafe configurations.
Validate all new interest parameters on sudo SetInterest to reject invalid or unsafe curves.
Add a guard in repay for an empty debt pool to prevent division-by-zero reverts.
Introduce a sudo-controlled pause mechanism to allow emergency stopping of critical operations during incidents.
Halborn performed a combination of manual and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of this assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of the code and can quickly identify items that do not follow the security best practices. The following phases and associated tools were used during the assessment:
Research into architecture, purpose, and use of the platform.
Manual code read and walk through.
Manual Assessment of use and safety for the critical Rust variables and functions in scope to identify any arithmetic related vulnerability classes.
Architecture related logical controls.
Cross contract call controls.
Scanning of Rust files for vulnerabilities (cargo audit)
Review and verification of integration tests.
| 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
0
High
1
Medium
1
Low
1
Informational
5
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Overpayment refunded in shares instead of base tokens | High | Solved - 10/28/2025 |
| Borrow limit checked in share units allows exceeding base-token cap | Medium | Solved - 11/06/2025 |
| Silent zero-share issuance from small deposits | Low | Solved - 10/08/2025 |
| Persistent DoS due to large idle-time interest accrual | Informational | Solved - 11/24/2025 |
| Lack of hard cap and unsafe default Interest parameters | Informational | Acknowledged - 11/28/2025 |
| Missing validation on sudo SetInterest allows invalid interest curves | Informational | Solved - 11/24/2025 |
| Division-by-zero on repay when the debt pool is empty | Informational | Solved - 11/25/2025 |
| No sudo-controlled emergency stop | Informational | Acknowledged - 11/28/2025 |
//
//
//
//
//
//
//
//
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
RUJI Lending
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed