Kamino Lend Fuzz Tests Summary

Kamino Lend is a decentralized lending platform deployed on the Solana blockchain that enables users to lend and borrow assets with flexible terms and interest rates.

Kamino engaged Ackee Blockchain Security to perform fuzz testing focused on the Kamino Lend protocol with a total time donation of 6 engineering days in a period between January 20 and January 30, 2025. Manual code review was not performed.

Kamino then engaged Ackee Blockchain Security to perform a second fuzz testing round of the Kamino Lend protocol with a total time donation of 15 engineering days in a period between June 23 and July 28, 2025.

Revision 2.1 was a review of the fixes of findings from the previous revision.

METHODOLOGY

The fuzz testing followed this systematic approach:

1. Code and architecture analysis
   1. 1. High-level review of the Solana program specifications, Rust sources, and instruction handlers to understand the program’s size, scope, and functionality.
      2. Analysis of Solana program entry points to identify instruction processors, account validation logic, and critical operations.
   1. Comparison of the Rust implementation and given specifications, ensuring that the program logic correctly implements everything intended.
2. Fuzz testing with Trident
   1. Interface Analysis
      1. Detailed examination of Solana instruction handlers and their account parameters
      2. Identification of Program-derived Addresses (PDAs), account ownership, and cross-program invocation patterns
      3. Mapping of account state transitions and Solana runtime data flows
   2. Initial behavior exploration
      1. Writing simple Trident fuzz tests to observe Solana program instruction execution
      2. Understanding account validation constraints and Solana runtime limitations
      3. Identifying unexpected program behaviors, panics, or edge cases in instruction processing
   3. Invariant definition
      1. Writing invariants based on expected Solana program properties and account state requirements
      2. Defining security-critical conditions for account ownership, balance constraints, and authority validation
      3. Establishing assertions for account state consistency and program-derived address integrity
   4. Complex stateful fuzz testing
      1. Writing complex Trident fuzz tests that model stateful interactions across multiple Solana instructions
      2. Testing transaction sequences and their effects on account states and program data
      3. Exploring interdependencies between instruction handlers and cross-program invocations
   5. Extended fuzz testing campaigns
      1. Running extended Trident fuzz testing campaigns to explore all edge cases in instruction execution
      2. Allowing the fuzzer to explore deep account state combinations and program execution paths
      3. Maximizing Rust code coverage and Solana instruction handler path exploration
   6. Dashboard analysis
      1. Continuous analysis of the Trident fuzz testing dashboard throughout the process
      2. Monitoring for program panics, instruction failures, and Rust code coverage metrics
      3. Identifying patterns that indicate potential Solana program vulnerabilities or runtime issues
3. Vulnerability assessment
   1. Classification of discovered Solana program issues by severity and impact on protocol security
   2. Development of proof-of-concept transaction sequences for critical findings
   3. Recommendations for Rust code remediation based on Trident fuzz testing results

SCOPE

The fuzz testing was performed on commit 829c1f3 and the scope was the following:

• Kamino Lending, excluding external dependencies.

The second fuzz testing was performed on the commit fe1ad10 with extended coverage, and the scope was the following:

• Kamino Lending, excluding external dependencies.

The third fuzz testing was done on given commits 4c58439, 89a6a81, and 542ffdb respectively. The findings reported in the previous revision were fixed – find the complete details including Kamino’s acknowledgments in the full audit report linked below.

FINDINGS

The classification of a security finding is determined by two sub-ratings: Impact and Likelihood. This two-dimensional rating makes the severity of issues more noise-free, without losing any information. The likelihood factor usually decreases severity of medium issues that would be just acknowledged by the team to infos and warning.

Our review resulted in 8 findings of Warning and Informational severity:

Critical severity

No critical severity issues were found.

High severity

No high severity issues were found.

Medium severity

No medium severity issues were found.

Low severity

No low severity issues were found.

Warning severity

W1: WithdrawObligationCollateralV2 subtraction overflow

W2: RepayAndWithdrawAndRedeemV2 subtraction overflow

W3: Unhandled panics

W4: Borrow limit excludes fees when validating borrow amount

W5: Liquidation instruction causes panic due to unwrap on None value

W6: Withdraw obligation collateral instruction reverts due to immutable owner

W7: Instructions cause panic due to division by zero when deposited value is zero

Informational severity

I1: Unused code

CONCLUSION

Ackee Blockchain Security recommended Kamino to:

• • investigate the findings and severity of the issues;
  • read and review the complete audit report; and
  • address all identified issues.

Ackee Blockchain Security’s full Kamino Lend fuzzing report can be found here.

We were delighted to audit Kamino and look forward to working with them again.