Audit name:
[SCA] LoanMeme | Loan Protocol Vault | Oct2026
Date:
Nov 9, 2026
Table of Content
Introduction
We express our gratitude to the LoanMeme team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Loan Protocol Vault is a Solana custody program for the loan protocol's funds that releases payments only with multi-party signed approval.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for LoanMeme |
| Audited By | Hamza Sajid |
| Approved By | Khrystyna Tkachuk |
| Website | https://app.loanmeme.io/→ |
| Changelog | 26/10/2026 - Preliminary Report |
| 30/10/2026 - Final Report | |
| Platform | Solana |
| Language | Rust(Anchor 1.2.1) |
| Tags | Vault, Fungible Token, Signatures |
| Methodology | https://docs.hacken.io/methodologies/smart-contracts→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for LoanMeme
- Audited By
- Hamza Sajid
- Approved By
- Khrystyna Tkachuk
- Website
- https://app.loanmeme.io/→
- Changelog
- 26/10/2026 - Preliminary Report
- 30/10/2026 - Final Report
- Platform
- Solana
- Language
- Rust(Anchor 1.2.1)
- Tags
- Vault, Fungible Token, Signatures
Review Scope | |
|---|---|
| Repository | https://github.com/LoanMeme/loan-solana-scs→ |
| Initial Commit | 510bfbc |
| Final Commit | ae349c0 |
Review Scope
- Initial Commit
- 510bfbc
- Final Commit
- ae349c0
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are provided. The README acts as a full specification, covering roles, accounts, instruction authorization, limits and assumptions.
A technical description is provided, including signed digest layouts, check order, transaction size limits and invariants.
Code quality
The code is split into focused modules, uses checked arithmetic and contains no unsafe code.
Signature verification uses custom Ed25519 instruction introspection with unnamed literal offsets.
The development environment is configured, with a pinned toolchain, a committed lockfile and a check script running formatting, build, tests and Clippy.
Test coverage
Code coverage of the project cannot be measured, because no coverage tooling is configured and the integration tests require a prebuilt program binary.
Deployment and basic user interactions are covered with tests.
Negative cases are covered extensively, including missing or substituted signers, limits, deadlines and substituted accounts.
Interactions by several users and roles are covered, including multiple vaults with different mints.
System Overview
Loan Protocol Vault is a Solana custody program, that holds the loan protocol's funds and releases them only with multi-party signed approval. It consists of one program, loan-protocol-vault, with the following accounts and instructions:
Vault: a PDA derived from vault_id that holds one SPL token, chosen at initialization and never changed. Its custody account is the vault PDA's associated token account. Deposits are plain SPL transfers, and the program keeps no balance accounting.
Instructions:
initialize: creates a vault and its custody account with a validated configuration. Callable by any fee payer.pay: transfers a borrow payout to the recipient's associated token account. Requires off-chain Ed25519 signatures from the operator, guardian_threshold guardians and the recipient.withdraw: transfers treasury funds to any recipient except the vault. Requires off-chain signatures from the operator and guardian_threshold guardians, and the treasury's transaction signature.set_config: replaces the whole configuration, including roles, limits and the paused flag. Requires the current operator, guardian_threshold current guardians, every incoming operator or guardian, and both the current and incoming treasury.pause: blocks all payouts and withdrawals. Callable by any single role.
Privileged roles
Operator: Its signature is required for every payout, withdrawal and configuration change, so its loss or refusal to sign halts the vault. It can pause the vault alone.
Guardians: Trusted partners running the protocol's verification programs. A threshold of them must approve every payout, withdrawal and configuration change. Any single guardian can pause the vault.
Treasury: A multisig, for example a Squads vault. It must sign every withdrawal and configuration change, so it can veto both. It can pause the vault alone.
Upgrade authority: Whoever holds the program's upgrade authority can replace every rule above. The specification assumes it is removed or held jointly by the same parties.
The operator, a threshold of guardians and the treasury together can change every role, raise every limit and withdraw all funds, bounded per transfer by max_payment and per day by daily_limit. The program cannot verify that these parties are independent.
Potential Risks
Upgrade authority. If the program remains upgradeable, its upgrade authority can replace every rule in the program, including moving all funds. The specification assumes the authority is removed or held jointly by the same parties, which cannot be verified from the code.
Collusion of the authorized set. The operator, a threshold of guardians and the treasury together can change every role, raise every limit and withdraw all funds. The program cannot verify that these keys are held by independent parties.
No timelock on configuration changes. Raised limits, new roles and a resumed vault take effect in the same transaction that approves them, leaving no window for monitoring or objection.
Operator and treasury liveness. Every payout, withdrawal and configuration change requires the operator's signature, and every withdrawal and configuration change requires the treasury's. If either key is lost, the vault cannot move funds or replace that key.
Signed payouts remain valid until their deadline. The program sets no maximum deadline, and a signed borrow payout can be executed by its holder at any time before it, whenever the vault is not paused.
Mint issuer control. The vault's mint is fixed for its lifetime. The issuer of a mint with a freeze authority, such as USDC, can freeze the custody account and block all payouts and withdrawals, and the program has no way to migrate funds to another account.
Cross-cluster signature reuse. Signed digests include the vault address but no cluster identifier. If the same program ID, vault_id and role keys are used on a test cluster and on mainnet, a signature produced on one is valid on the other.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-2008 | Missing Cluster Binding In Digest Function Allows Replay Of Test Cluster Payouts On Mainnet | fixed | Medium | |
| F-2026-2008 | Repeated Pause In Pause Instruction Allows A Single Role To Freeze Vault Funds | fixed | Low | |
| F-2026-2008 | Missing Destination Owner Check In Pay And Withdraw | fixed | Observation | |
| F-2026-2008 | Imprecise Error Messages For InvalidRoles And Unauthorized | fixed | Observation | |
| F-2026-2008 | Missing Proof Of Possession For Roles In Initialize Instruction | accepted | Observation |
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/LoanMeme/loan-solana-scs→ |
| Initial Commit | 510bfbcc3fb5eb2eb9bf36d920bfff4827e4f968 |
| Final Commit | ae349c0000bb93f204d82abf385f44592be63b15 |
| Whitepaper | - |
| Requirements | Readme.md |
| Technical Requirements | Readme.md |
Scope Details
- Initial Commit
- 510bfbcc3fb5eb2eb9bf36d920bfff4827e4f968
- Final Commit
- ae349c0000bb93f204d82abf385f44592be63b15
- Whitepaper
- -
- Requirements
- Readme.md
- Technical Requirements
- Readme.md
Assets in Scope
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.
Frameworks and Methodologies
This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.